Conform to RFC-7231 (HTTP) (HTTP/1.1): Semantics and Content

[andreujuanc]

Hi, some of the endpoints are not confirming to the general practice of http and rest semantics.
This makes it very difficult to integrate with existing software that might have issues with the current spec.

One of the key items we observed were the /quote/in /quote/out endpoints where they are supposed to create a quote and return it. Therefore they are not only retrieving information but also requesting a state change in the server.

According to the RFC https://www.rfc-editor.org/rfc/rfc7231#page-24 Section 4.3 Method Definitions:

The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request.

Then there are other issues with the body being send with a GET:

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.

We observed AWS APIGateway failing to process a GET request with a body, we are just scratching the surface here.

Another problem is Cache, according to the RFC:

The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [RFC7234]).

This mean that some server and client applications will cache GET request by default assuming that it's not a state changing operation.

Would love to hear more from the group that created this spec, and understand the reasoning behind it.

IMHO these requests can be changed to be a POST or even a PUT without affecting functionality.

Thanks