What do you think of sending a body in HTTP 'GET' request?

I don't see why one would need it. It's technically not disallowed to send one, but a lot of libraries don't handle it.

Semantically, by calling GET, you'd specify your request in the URL and in the HTTP header. Putting something in your body... why?

Let's say I want to
GET /starbucks/coffee
Body: {"type":"expresso",extras:["whipped cream","cinnamon"]}
Accept:cup/carton
Content-Length:extra-large
That is the only usage I can see though

@melezorus34 I regret there's no way to increment multiple times on dR.

@melezorus34 No.
This would be URL/Custom header parameters.

GET /starbucks/coffee?type=espresso&extras=whipped%20cream&extras=cinnamon

OR

GET /starbucks/coffee
...
Headers (can contain JSON!)
Coffee-Type "\"espresso\""
Coffee-Extras "[\"whipped cream\", \"cinnamon\"]"

It's *very* widely accepted practice that you just don't do that, and you'll likely cause all sorts of issues if you do.

If you're *creating* a new coffee, then you want to use POST, with the parameters in the body. If you're retrieving an existing one, then GET makes sense, but use URL parameters instead.

@kescherRant what if I my Device Agent is a "White Starbucks Girl Webkit 63.0a"? I need to put paramaters longer than 300 characters just to satisfy my InstaAI database

Oh boy, I really am bored.

Never found a need. GETs should be as simple as GET by id or GET all with few filters applied. Anything else is a sign of mutation of resource

@melezorus34 If you parameters are longer than 300 characters, use the headers approach.

Or, maybe you should POST an order. Where you can then use a body with JSON.

@kescherRant Coffee-Extras is only defined in HTCPCP/1.0 so you have to specify that in the request line

https://tools.ietf.org/html/rfc2324

@retnikt You can set custom headers freely. I'm currently making use of that in one of my projects.

Jesus! REST is full of inconsistent conventions. Why would I want to post a body in GET? Why the fuck not? Why should I make workarounds with headers or url params? Fucking web logic!

@Lensflare thanks.

I have had this problem where the user can specify an arbitrary DSL-Query to build a filter.
This easily exceeds the max URL length.
Then we were stuck with either POST w/body or GET w/body or GET w/header.
We decided to just POST although it’s semantically a GET. ¯\_(ツ)_/¯ fuck cares. Ist just our FE w/ our BE.
Sad is, that you can’t share links w others to specify the same search.

@dder On a very similar problem we ended up creating a db table, updating parts of queries using ajax and referring to them in the URL by hash. Since each record could be shrunk to under half a KByte, we ended up just adding a routine to clear up old items in the cache when it hits 4GB, which it never will.

Spec states that request message bodies have no defined function. You can choose to include one, but don't expect any broad support if you do so. Might work fine in your current framework, move to another, might now, no proxy server or gateway is obligated to allow it.

You may find that older servers don't support it at all, because older versions of the spec states that GET semantics defined no body, so many tools still adhere to the outdated spec.

https://tools.ietf.org/html/...

@molaram , I worked on a project (only client side) where API developer was doing it on multiple services and I thought this is wrong way to do it and I confronted him. He had no argument and said this is legit.

As a Frontend person:

(...)

*sighs

(...)

NOO, FUCK YOU, NO!!! I REFUSE TO USE YOUR API AND WON’T HELP YOU WITH THAT DAMN NPM PROBLEM YOU GOT.

thanks.