4 ms·
Is there some benefit to implementing it as a GET instead?
by smarx 12y ago
Is there some benefit to implementing it as a GET instead?
- mmastrac 12y agoIf it's an unauthenticated call you can use a browser, but if all the calls require a header like that, I don't see a reason to.
- Revell 12y agoCaching for one. I just don't see a reason for moving as much as possible to POST since this seems to go against what the different methods (GET, HEAD, POST, PUT, DELETE, etc) were meant for.
- dragonwriter 12y ago> I just don't see a reason for moving as much as possible to POST since this seems to go against what the different methods (GET, HEAD, POST, PUT, DELETE, etc) were meant for. Arguably, HTTP-based RPC with consistent use of POST is a lot more straightforward of a model than the kinda-sorta-REST-without-HATEOAS that a lot of APIs use, and arguably for APIs whose scope is a particular server and not the kind of generality that the web as a whole itself (the archetypical REST service) provides, POST-based HTTP-RPC is a more natural choice than REST.
- smarx 12y agoThe new API does support GET for requests that are cacheable (e.g. fetching a file or thumbnail). The RPC-style endpoints all use POST and are not cacheable.
- untog 12y agoIt helps to clarify what will happen. GET requests should never alter the data in the backend, wheras PUT, POST and DELETE would.