REST API Best practices: args in query string vs in request body

Question

What are the best practices and considerations of choosing between 1 and 2 above?

Usually the content body is used for the data that is to be uploaded/downloaded to/from the server and the query parameters are used to specify the exact data requested. For example when you upload a file you specify the name, mime type, etc. in the body but when you fetch list of files you can use the query parameters to filter the list by some property of the files. In general, the query parameters are property of the query not the data.

Of course this is not a strict rule - you can implement it in whatever way you find more appropriate/working for you.

You might also want to check the wikipedia article about query string, especially the first two paragraphs.

I'll assume you are talking about POST/PUT requests. Semantically the request body should contain the data you are posting or patching.

The query string, as part of the URL (a URI), it's there to identify which resource you are posting or patching.

You asked for a best practices, following semantics are mine. Of course using your rules of thumb should work, specially if the web framework you use abstract this into parameters.

You most know:

• Some web servers have limits on the length of the URI.
• You can send parameters inside the request body with CURL.
• Where you send the data shouldn't have effect on debugging.

The following are my rules of thumb...

When to use the body:

• When the arguments don't have a flat key:value structure
• If the values are not human readable, such as serialized binary data
• When you have a very large number of arguments

When to use the query string:

• When the arguments are such that you want to see them while debugging
• When you want to be able to call them manually while developing the code e.g. with curl
• When arguments are common across many web services
• When you're already sending a different content-type such as application/octet-stream

Notice you can mix and match - put the the common ones, the ones that should be debugable in the query string, and throw all the rest in the json.