Newsletter – Week 47, 2020

News:

Articles:

Videos:

Newsletter – Week 46, 2020

News:

Articles:

Videos:

GET/POST

When you design search API for REST service there are multiple options technically available:

  • use a GET with payload
  • use a GET with URL query parameters
  • use a POST with payload

In the previous post To be or not to be… I shared my thought about the first option (GET with body) which actually is only a technical option and definitely not the best choice.

So, let’s talk about the other two below.

When we think about the GET with URL query parameters usage we should remember all requested data is included in the URL and there is a restriction on size:

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.

HTTP/1.1, 1999 (RFC 2616)

The good moment here is the most web servers have a quite big limit of 8192 bytes (8 Kb) for this case and this value usually configurable.

Also, when GET with URL query parameters is used there could be a URL size restriction in the browser, for example, this is the URL size limit in Chrome browser:

Chrome limits URLs to a maximum length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication.

Guidelines for URL Display (Chromium)

So, even considering all these restrictions in the general case there shouldn’t be any issue with the URL length.

But what if we replace GET with POST and put our request parameters into the request payload. Looks pretty good and without URL size limits now, but there are caveats as well:

…the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

HTTP/1.1, 1999 (RFC 2616)

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.

HTTP/1.1, 1999 (RFC 2616)

Considering statements above GET which is “safe” and “idempotent” has an important benefit against POST – the cache mechanism support.

The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching

HTTP/1.1, 1999 (RFC 2616)

As we can see, the usage of POST method for search provides mostly only one benefit – the size of the request payload.

So, comparing both options: GET with URL query parameters is preferable for search when POST with payload makes sense only in case of complex queries with tons of search parameters.

Bonus

Even if you have a quite complex search logic there is still a chance to get it implemented in an elegant manner in GET with URL parameters form. For example, let’s see Google image search API:

Which is transformed into a short and elegant URL like below:

https://www.google.com/search?as_st=y&tbm=isch&as_q=landscape+city&as_epq=&as_oq=&as_eq=&cr=countryUS&as_sitesearch=&safe=images&tbs=ctr:countryUS,isz:l,itp:photo,ic:color,ift:jpg

Newsletter – Week 45, 2020

News:

Articles:

Videos:

Newsletter – Week 44, 2020

News:

Articles:

Videos:

Newsletter – Week 43, 2020

News:

Articles:

Videos:

What was that?

You might notice recently I changed my blog primary address from javadevlab.org to ilapitan.com, there were multiple reasons to do so, but the main of them is that the previous name (javadevlab.org) doesn’t fully meet my goal for this blog.

In this blog, I want to share different topics and many of them aren’t related to Java programming language. The scope of these topics is much broader and related to the software engineering field in general. As I don’t want to connect my blog to any technology anymore, so selected the most simple way to associate the blog with my name itself.

I consider it as the next step in my attempt to share something interesting and ideally helpful to you. It is like the blog v2 version for me personally.

So, happy releases!

Newsletter – Week 42, 2020

News:

Articles:

Videos:

Newsletter – Week 41, 2020

News:

Articles:

Videos:

To be or not to be…

Let’s talk today about a quite interesting question related to the HTTP protocol. This question is: to be or not to be the body in HTTP GET request?

This question has been raised during the discussion about the search API. For the search API design there are such possible options:

  • use a GET with payload
  • use a GET with URL query parameters
  • use a POST with payload

This article will be covering the first option, the other two options I’m going to cover in the next article.

Maybe not everyone knows but based on HTTP specification GET request can have a body the same as we get to see in the POST request.

The first version of HTTP called 0.9 included only one GET request method, no headers and request body are supported.

The client sends a document request consisting of a line of ASCII characters terminated by a CR LF (carriage return, line feed) pair.

HTTP/0.9, 1991

then with RFC 1945 GET method was defined as:

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

HTTP/1.0, 1996 (RFC 1945)

so, the body is not a part of URI and should not be included in the request. But, newer RFC 7231 comes into play:

The GET method requests transfer of a current selected representation for the target resource.

HTTP/1.1, 2014 (RFC 7231)

and GET method definition to become not so clear as the previous one, but the question with the body in request now is pretty clear:

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.

HTTP/1.1, 2014 (RFC 7231)

Clear, right. Or, not so clear? So, technically the body can be present but there is no guarantee that it will be processed correctly.

Moreover, there is a rule defined in RFC 2616:

A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

HTTP/1.1, 1999 (RFC 2616)

Let’s try to look into the new RFC 7540 which is totally different, but I think it has one important moment.

This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses.

An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame…

HTTP/2.0, 2015 (RFC 7540)

So, considering all above the final decision is even if technically GET request could have a body, this is strongly not recommended to use GET with the body in request due to unpredictable result of request processing. You can read more about other options there.