HTTP method to use when processing client data to produce output

Question

I have a requirement to add an endpoint to my API to read a large encrypted input file and return some decrypted metadata from the file.

The ideal solution to me would be to use a GET endpoint and take the encrypted blob in as a query parameter, but I'm concerned about URI length limits in different implementations.

Placing the data as a body parameter appears to be a bad idea (HTTP GET with request body), not least because I'm worried it will wreak havoc with server-side caching solutions that do not expect any information in the body of a GET.

What is the correct HTTP method to use when taking data from a client and processing it to produce output?

UPDATE My current thoughts are taking the data in the body of a POST, and returning a 201 with the LOCATION header containing a GET URL that references the resource (i.e., the decrypted metadata). As the resource itself is not persisted in any way, I will have to place the metadata in as a query parameter to the GET. But as the metadata is length-limited (an application constraint), this shouldnt be a problem.

Answer 1

I would certainly avoid using an HTTP GET with a request body.

To me, the most appropriate HTTP verb would indeed by a POST. If the resulting resource is not to be persisted then I would not return a 201. Moreover, in your application this could compromise the decrypted metadata which will now become a query string parameter. Instead just return a 200 with the content, which is perfectly reasonable for a POST operation.

Answer 2

POST is good, but don't worry about suggesting a LOCATION header. It's fine to return your metadata in the POST response body with 200 OK.

From the RFC:

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.