4 ms·
"Overall, we’ve simplified our use of HTTP. For example, most endpoints always use HTTP POST, including those that return structured data." Why? Why would you
by Revell 11y ago
"Overall, we’ve simplified our use of HTTP. For example, most endpoints always use HTTP POST, including those that return structured data."
Why? Why would you use a POST call for the first endpoint they demonstrate, users/get_current_account
curl -X POST https://api.dropbox.com/2-beta/users/get_current_account \
--header "Authorization: Bearer <access-token>" \
--header "Content-Type: application/json" \
--data "null"
Why not implement that as a GET-call?
- smarx 11y agoIs there some benefit to implementing it as a GET instead?
- mmastrac 11y 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 11y 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 11y 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 11y 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 11y agoIt helps to clarify what will happen. GET requests should never alter the data in the backend, wheras PUT, POST and DELETE would.