Live data from Hacker News

A preview of the new Dropbox API v2

blogs.dropbox.com

1–9 of 9 posts

Re: A preview of the new Dropbox API v2

#2
"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 " \
    --header "Content-Type: application/json" \
    --data "null"
Why not implement that as a GET-call?

Re: A preview of the new Dropbox API v2

#3
post #2

"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 " \ --header "Content-Type: application/json" \ --data "null" Why not impl…

Is there some benefit to implementing it as a GET instead?

Re: A preview of the new Dropbox API v2

#4
post #3
post #2

"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 " \ --header "Content-Type: application/json" \ --data "null" Why not impl…

Is there some benefit to implementing it as a GET instead?

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.

Re: A preview of the new Dropbox API v2

#5
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?

Re: A preview of the new Dropbox API v2

#6
post #3
post #2

"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 " \ --header "Content-Type: application/json" \ --data "null" Why not impl…

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.

Re: A preview of the new Dropbox API v2

#7
post #6
post #3

Earlier quoted context omitted.

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.

Re: A preview of the new Dropbox API v2

#8
post #6
post #3

Earlier quoted context omitted.

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.

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.

Re: A preview of the new Dropbox API v2

#9
post #3
post #2

"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 " \ --header "Content-Type: application/json" \ --data "null" Why not impl…

Is there some benefit to implementing it as a GET instead?

It helps to clarify what will happen. GET requests should never alter the data in the backend, wheras PUT, POST and DELETE would.