Use Case of HTTP GET Request with a Body

api-designhttp-requestweb-applications

I am maintaining a old .aspx page in which all the data required by the page to show the content is passed in the URL of the GET request as a part of query string. The result of this is that, as we keep on adding features, the URL keeps getting bigger.

I am thinking of shifting all the parameters from the query string to the Body of the GET request.

Is it a good design decision and what is the use case of a body in GET request?

Best Answer

GET requests with a body are supported in the HTML specs.

See the Stack Overflow question Is this statement correct? HTTP GET method always has no message body for a discussion.

However, it's unusual. You will surprise people with that solution. Simply switching to a POST is a better idea.

The only downside (upside?) is annoying RESTfulness acolytes.

Related Solutions

HTTP – Why GET Request Shouldn’t Change Data on Server

This is not advice.

A GET is defined in this way in the HTTP protocol. It is supposed to be idempotent and safe.

As for why - a GET can be cached and in a browser, refreshed. Over and over and over.

This means that if you make the same GET again, you will insert into your database again.

Consider what this may mean if the GET becomes a link and it gets crawled by a search engine. You will have your database full of duplicate data.

I also suggest reading URIs, Addressability, and the use of HTTP GET and POST.

There is also a problem with link prefetching in some browsers - they will make a call to pre-fetch links, even if not indicated so by the page author.

If, say, your log out is behind a "GET", linked from every page on your site, people can get logged out just due to this behaviour.

API Design – How to Handle GET Requests with Access Tokens

Option 4: Authorization Headers and RFC 6750 (Bearer Tokens)

The solution you are looking for has already been specified as part of the OAuth2 standard, but it stands by itself and will be useful in your scenario.

https://www.rfc-editor.org/rfc/rfc6750

All requests from the client will pass in a bearer token (your access token), and it looks like any other request header to the server. The request itself looks like this:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Since it's a widely implemented public standard, you don't have to worry about defining behaviour - just point client-side developers at the RFC. You might also consider implementing the rest of the OAuth2 standard as both a resource server and an authorization server, but that is a lot more work.

Best Answer

Related Solutions

HTTP – Why GET Request Shouldn’t Change Data on Server

API Design – How to Handle GET Requests with Access Tokens

Related Topic