4 ms·

I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful. We had a

I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful. We had a couple of problems with GET requests: all of our data ended up in the url (we have too much info that has to be passed, we stopped working on some browsers), and the data returned could be cached (which is a HUGE problem for us). Now, POSTs can also be cached, but there are easy ways around it...you can do the same thing with a GET, but that means adding more information to the url. Anyway, one we got to the point of forgoing all GET requests, we ended up just doing everything with a POST for simplicity.

xrstf 11y ago
I did the exact same thing in a project of mine. We're shifting away from that and put our data in cookies, so we can cache some of the things our API send out.
- nulltype 11y ago
  You can also use localstorage these days. It's great not having to send data on every request.
nulltype 11y ago
Yeah, REST is nice for some things, but for normal APIs, you're calling them from a programming language, so calling remote functions (RPC) is very similar conceptually to calling local functions. You might not be able to guess the paths as easily as REST(?) but then again trying to make things REST style doesn't always work out when the things don't allow all the REST verbs or don't fit into a hierarchy, etc. For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy. From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work. Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.

xrstf 11y ago

I did the exact same thing in a project of mine. We're shifting away from that and put our data in cookies, so we can cache some of the things our API send out.

nulltype 11y ago
You can also use localstorage these days. It's great not having to send data on every request.

nulltype 11y ago

Yeah, REST is nice for some things, but for normal APIs, you're calling them from a programming language, so calling remote functions (RPC) is very similar conceptually to calling local functions. You might not be able to guess the paths as easily as REST(?) but then again trying to make things REST style doesn't always work out when the things don't allow all the REST verbs or don't fit into a hierarchy, etc. For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy. From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work. Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.