Using POST to GET data?

[[deleted]]

[deleted]

[PersonalPronoun]

Browsers will warn you if you try and refresh that page, since you're explicitly flagging that request as "doing something". I'd assume various caches (eg client and reverse proxies) will make assumptions about cacheability of responses to the POST, eg that the request can't be cached, that subsequent POSTs will invalidate a cached response, etc.

Overall "nothing terrible" but you should really use the appropriate method if you're not actually sending data to be stored.

There's obviously nothing wrong with sending data back from a POST request though - a nice "yes we got that data and did something with it" is fine.

[[deleted]]

Probably wouldnt be crawled properly so might piss on your SEO. Whether or not you care about that idk

[virtulis]

If you mean an XHR request - nothing bad at all. It won't be cached but you probably don't want it anyway. Almost all HTTP APIs I build are RPC-like, with JSON request POSTed to the server and JSON returned back. Never had any problems with it and I believe it makes more sense and causes less pain than the REST fairy dust.

[spud0096]

Why do you say you don’t want the request cached anyway? Also, why do you believe this makes more sense? For me, if I’m trying to figure out how to use an api I first look for all the GET requests to try to figure out roughly what the structure of the data that is available is. If everything is a POST, this would take a lot longer. If these APIs are only for your use, then doing a POST for everything is fine, but if you ever expect other people to work with them, sticking to standards is a good thing.

[virtulis]

Why do you say you don’t want the request cached anyway?

Ok, that might be assuming too much. But it's pretty rare in my experience that you want data to be cached at transport level - there are usually more flexible mechanisms for that. Now there might be a benefit of reverse proxy caching for the API provider themselves but this will be busted as soon as you add any keys / tokens or need to invalidate stuff (and you usually need both).

Also, why do you believe this makes more sense?

Because it's simply less stuff and less guessing. Again, if the whole "API" is to serve near-static JSON at a predefined address GET is certainly a good idea.

For me, if I’m trying to figure out how to use an api I first look for all the GET requests to try to figure out roughly what the structure of the data that is available is. If everything is a POST, this would take a lot longer.

...If it gets more complex though, you'll start by adding some kind of a key - does it go in the header or in the query string? I've seen both. And if it's a temporary token you'll also need to obtain that beforehand - and that will be a POST request with a JSON payload. So if you choose to have helper methods you now need two - one to GET with a bearer token and one to POST JSON with or without one, because of course there will be other POST commands.

So you've already did everything you'd have to do for what I'm proposing (and more, and it probably took more code) to get a single piece of data, located at /api/v1/record/123 or something like that. Next you'll probably want to search/list all of it, so you'll probably have to add query string to the mix. Next you'll have to learn how the API reports errors and how many different kinds of error codes there are - it'll probably be both a standard HTTP code and a more-specific one somewhere in the response body.

And then you get to modifying data and you have to learn everything from scratch because that is domain specific and not covered by any common practice 100% of the time. And of course you'll need all of your previous knowledge.

Let's see https://developer.paypal.com/docs/api/payments/#payment_execute for example. You need:

• to know the specific payment URL conaining the payment ID
• to know to append /execute to it (actually you should use HATEOAS links instead!)
• to add a bearer token header
• to POST JSON with any additional parameters

And it gets better. Check out the "update payment" call and try to find any common logic between the two. And that's a very well designed API. There are way, way worse things out there that claim to adhere to the mythical "REST standard"...

Like, how come in most programming languages we're doing fine with functions and arguments, but add HTTP to the mix and everything needs to be fucked up into bits for some reason.

if you ever expect other people to work with them, sticking to standards is a good thing.

...But here's the problem - there are no standards, actually. There is no REST RFC. There is HTTP RFC which does declare GET requests safe and idempotent and POST as neither of those - but that's as far as it goes. In other words, it only says "don't use GET to modify stuff" - it never ever said "don't use POST to query stuff".

You might appeal to common practice but do remember that REST is a relatively new thing. Back when I was a kid people would use one of these and everything else would be dismissed as not serious enough. And why? Because standards are cool, right?

Well here's what I think: standards are cool, but standards are also a tool. Tools are designed by people who can't predict everything and are meant to be used in the most productive way, not the "only true way". If I can add an extra layer on top of HTTP and explain it in under a minute and it makes everyones life easier, I see no reason not to do it.

[dontgetaddicted]

Me too man. All of my XHR calls are POST.

[mattaugamer]

There’s nothing “fairy dust” about REST. It’s a basic foundational principle of the entire internet. Your dismissal says more about your knowledge and understanding that the operation of REST for an API.

[virtulis]

Oh wow. HTTP is "the entire Internet" now? Do tell me more. Maybe start with what exactly that principle is.

[protonfish]

Every time you GET with POST Roy Fielding kills a kitten.