Why Would You Use POST Instead of GET for a Read Operation?

Exploring scenarios in which we might want to deviate from the standard.

Normally, I’d say “no, you don’t”; because GET is for read operations and POST is meant for write (e.g. create) operations.

But today I was reading the draft of some OpenAPI specifications, in which one of our REST API consumers suggested having a new endpoint to look up users by their phone number. And they wanted this to be a POST endpoint. So I asked myself: why would they want this?

Security reasons

When a get GET request is received, many servers log information about the incoming request. Most of them will log the whole requested URL including query parameters, which might include sensitive information. In our case, we would be potentially logging the phone number of our users.

Let’s see if we can verify this claim. We will spin up a dockerized NGINX…

> docker run -it --rm -d -p 8080:80 --name web nginx

…and see what happens when we try to access http://localhost:8080/user/1234567890 (assuming 1234567890 to be the user’s phone number.)

172.17.0.1 - - [18/Oct/2020:13:46:35 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (***) ***" "-"
2020/10/18 13:46:46 [error] 28#28: *1 open() "/usr/share/nginx/html/user/123456789" failed (2: No such file or directory), client: 172.17.0.1, server: localhost, request: "GET /user/123456789 HTTP/1.1", host: "localhost:8080"

Even thought it returned a 404 error, we can see that the whole URL path gets logged. Even the first request to /, which was successful, logs the whole path. If this system would be hacked, logs could be retrieved and phone number information could potentially be exposed and leaked.

URL length

Browsers and HTTP servers can have a maximum URL length. For example Microsoft Internet Explorer is limited to 2,048 characters, and Apache HTTP Server can handle up to 4,000 characters in a URL. In our case, given that a telephone number might have a maximum length of 9 characters, there would be no reason to use POST instead of GET.

Accountability

There is a very interesting point in the W3C’s paper URIs, Addressability, and the use of HTTP GET and POST:

Use POST if […] (the) user be held accountable for the results of the interaction.

Requesting a user’s profile exposes an individual’s personally identifiable information. One could argue that requesting this data should not be done lightly.

But isn’t this a semantic decision, just as much as the decision of using GET for because it is a read operation?

In the end, common sense and reason should prevail. Even if it goes against the REST principles, if one doesn’t want to risk PII like phone numbers to be logged, then go ahead and use POST instead of GET.