REST API HTTP GET with Body

Question

I'm actually rewritting some APIs (in ASP.Net Core 3.1) we have at work and we try to make them RESTFull. I run into some methods where It should be called with HTTP GET because it's for retrieving some data but the parameters are wrapped in a pretty large DTO.

So I was asking myself how to deal with it :

• Let it put the DTO in the URL but then what are the limitation in size?
• Put a body in the HTTP GET request. I made some search but the results I found were old. Apparently it's allowed but discouraged back in the time
• Use HTTP Post, but then it's not REST because POST should be used to create data

I think the better solutions will be to use HTTP Get with body (according to this article https://thecodebuzz.com/http-get-delete-request-body-guidelines/ it's possible)

Have someone had the same issue? What are the guideline now a days?

Thanks for your thoughts

Answer 1

I think the better solutions will be to use HTTP Get with body

RFC 7231 thinks otherwise:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

You can't count on general purpose components doing useful things with the body. For instance, caches will be using the target-uri as the primary cache key, and won't be considering the body at all. So strange behavior is likely there.

In effect, GET with a body is only going to work if you control the client, the web server, and the components in between. And if that is the case, you might as well define your own HTTP method with the semantics that you want it to have.

For example, you might look into HTTP SEARCH, and see if those semantics are a better fit for what you are trying to do.

That said, if you are trying to color inside the lines, it is okay to use POST.

POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”

---

it's not REST because POST should be used to create data

REST doesn't define any sort of "create" constraint. REST says "use the appropriate method defined in the uniform interface"; HTTP says "use POST when no more specific method fits".

But if you are in an environment that won't accept that... one way to achieve what you want without "breaking the rules" is to think about creating a new resource that is the results of your query. So we POST some information, and that information gets associated with a new URI controlled by the server, and then subsequent attempts to GET the resource give you the results you want.

POST /foo

201 Created
Location: /c30e910e-7baa-4c31-9481-4c84c12884a1  
...Other Headers...

GET /c30e910e-7baa-4c31-9481-4c84c12884a1

200 OK
Content-Location: /c30e910e-7baa-4c31-9481-4c84c12884a1
...Other Headers...

The Answer

Following the standards, you can combine those two ideas to save a round trip

POST /foo

201 Created
Location: /c30e910e-7baa-4c31-9481-4c84c12884a1  
Content-Location: /c30e910e-7baa-4c31-9481-4c84c12884a1
...Other Headers...

The Answer

From there, it's a small step to

POST /foo

200 OK
...Other Headers...

The Answer