2

I'm thinking about creating a REST API for an existing pure HTTP-based web service.

Until now, clients can send HTTP POST requests to the service for retrieving data. The HTTP bodies of these requests contain something like query parameters. It is a XML dialect. These queries can often have a size of more than 30 kB.

Also, encryption is required for queries. So, the query parameters can't be transfered by HTTP GET as a query string.

My question is: does it violate the REST principle "POST changes server state", if I use HTTP POST for retrieving data?

After every retrieving action (successful or not), a log-entry is added to a logging-table in a database.

Update

So, the query parameters can't be transfered by HTTP GET as a query string

As I've learned from the comments and the answer, the query string is encrypted. But it's not recommended to transfer security sensitive data within the query string.

JimHawkins
  • 4,843
  • 8
  • 35
  • 55
  • 1
    Yes, POST is for creating data. Also, if you use SSL you don't need to worry about encrypting parameters. – Stan Sep 01 '16 at 15:14
  • 1
    @Stan - sure, HTTPS uses encryption. But the URL - including query string - is never encrypted. This is one of the two reasons why the clients have to put the query to the HTTP body – JimHawkins Sep 01 '16 at 15:17
  • 1
    No, it's encrypted as well. It's not a good idea to pass sensitive info over querystring, however **it is safe against traffic sniffing**. – Stan Sep 01 '16 at 15:18
  • query strings are encrypted, but they are stored to accesslogs - http://stackoverflow.com/questions/2629222/are-querystring-parameters-secure-in-https-http-ssl – Denys Kurochkin Sep 01 '16 at 15:20

1 Answers1

3

While it technically violates REST, if your query parameters are large, which it sounds like they are, then POST may be the only way to go. Also, not all clients support GET with body parameters.

ElasticSearch also allows POST queries:

Both HTTP GET and HTTP POST can be used to execute search with body. Since not all clients support GET with body, POST is allowed as well. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html

As does Azure Search API
https://msdn.microsoft.com/en-gb/library/azure/dn798927.aspx

The point I'm trying to make is that while it goes against REST principals, sometimes rules are there to be broken.
You could always think of it as POSTing (creating) a query ;-)

As a side-note re: GET requests / query strings

The entire text of an HTTPS session is secured / encrypted by SSL.
This includes the query and the headers.
In that regard, a POST and a GET would be exactly the same.

Alex
  • 37,502
  • 51
  • 204
  • 332
  • One tiny addition: the semantics of `GET` changed between [RFC2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3) and [RFC7231](https://yada.juxt.pro/spec/rfc7231#section-4.3.1) slightly. While the former one didn't really forbid to send payload with a GET request, plenty of implementations assumed it is and therefore either ignored it or responded with an error if a payload was available. The new spec, however, clearly states that the semantic of the payload is just undefined in a GET request and may break older servers. [See also](http://stackoverflow.com/a/35794273/1377895) – Roman Vottner Sep 01 '16 at 18:03
  • Thanks for your answer, Alex. You got a typo there. You meant "REST principles", I guess. I've seen a lot of people fiddling with the idea of creating a resource for the search. I guess it could work. After creating the search resource, you could query using a GET request and then have your results, maybe even in a search-results resource. Maybe doing it like that wouldn't break REST, right? Now about security, query parameters sent with GET will be logged into your webserver logs and later can be accessed, so it's unsafe to send sensitive data using GET. Prefer POST in that case. – Igor Donin May 01 '22 at 13:53