Re: Bad Request Errors Hints

tomglod

So, I'm new to the dropbox API, and the work has been a giant pain.
Mainly because of the design of the dropbox api and the unusual decisions that were made.
I am writing this in hopes of saving someone else the time it took to find this out.

When you get "400 Bad Request" error when accessing endpoint such as "get current user" or "get usage" ...
The error coming back will be something like "expected null, got body".

You would think that not including any JSON would = null.

But you'd be wrong.

The Dropbox API requires the word "null" as the body of the payload. ITS NOT EVEN SUPPOSED TO BE ENCODED IN JSON. just the string .... null

Is this documented you ask? No, no its not.

Oh yes, and then there is JSON in the headers, that is also severely abnormal.

As a matter of pure feedback, this has been a horrible experience, I can't wait to be done with the integration work.
Besides this, thanks for the API and the ability to integrate Dropbox in our apps.

Tom

Greg-DB

Thanks for the feedback!

For reference for anyone reading, if there are no parameters to send for an RPC endpoint like this, you can omit the request body as long as you also omit the "Content-Type" header (since there is no request body to describe).

To illustrate this, here's some examples of working usage of the mentioned /2/users/get_current_account endpoint, which doesn't require any parameters. The first way is the simplest way to call this endpoint:

# works, because no request body is sent, and accordingly no Content-Type is specified
curl -X POST https://api.dropboxapi.com/2/users/get_current_account \
    --header "Authorization: Bearer <ACCESS_TOKEN>"

# works, because a request body is sent with the JSON "null" (since there are no parameters), with the corresponding "Content-Type: application/json"
curl -X POST https://api.dropboxapi.com/2/users/get_current_account \
    --header "Authorization: Bearer <ACCESS_TOKEN>" \
    --header "Content-Type: application/json" \
    --data "null"

tomglod

That may be true, but you may also see a "expecting Content-Type" error, urging you to include a content-type.

Здравко

@tomglod wrote:
That may be true, ...

Hi @tomglod,

It is definitely true! As Greg mentioned, meaning of content depends on content type. Empty string is definitely not valid JSON content type!!! Passing empty string as JSON is... a bug. To represent nothing, correct representation is null (by the way this is not a string - string "null" would be wrong too). Keep in mind that quotes that appear on command line (untagged) get stripped by the shell.

You can pass arguments as nothing when missing both content-type and the body as already discussed.

@tomglod wrote:
..., but you may also see a "expecting Content-Type" error, urging you to include a content-type.

Dropbox API cannot be "urging you to include content type"! If you have included inappropriate content type, error response will show you possible correct variants while suppose you want to pass something. Here the message is missing the option of missing content type - something that may be improved. If something else urge you though, try figure out where it comes from - it may be from your environment.

Good luck.