A preview of the new Dropbox API v2
blogs.dropbox.com"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"
Is there some benefit to implementing it as a GET instead?
Caching 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.
> 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.
The 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.
It helps to clarify what will happen. GET requests should never alter the data in the backend, wheras PUT, POST and DELETE would.
If 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.
I used to love Dropbox! There are so many options nowadays, though. Oh! This reminds me of a question I've been meaning to ask: Is there any way I can use this API to retrieve information about how much of my data has been handed over to the United States government?