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

A REST API can have arguments in several places:

1. In the request body - As part of a json body, or other MIME type
2. In the query string - e.g. /api/resource?p1=v1&p2=v2
3. As part of the URL-path - e.g. /api/resource/v1/v2

What are the best practices and considerations of choosing between 1 and 2 above?
2 vs 3 is covered here.

> 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.

The reasoning I've always used is that because POST, PUT, and PATCH presumably have payloads containing information that customers might consider proprietary, the best practice is to put all payloads for those methods in the request body, and not in the URL parms, because it's very likely that somewhere, somehow, URL text is being logged by your web server and you don't want customer data getting splattered as plain text into your log filesystem.

That potential exposure via the URL isn't an issue for GET or DELETE or any of the other REST operations.