HTTP method used when processing client data to receive output
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 for me would be to use a GET endpoint and include the encrypted blob as a request parameter, but I am concerned about the URI length limitations in different implementations.
Placing data as a body parameter seems like a bad idea ( HTTP GET with a request body ), not least because I'm worried it will harm server-side caching solutions that don't expect any information in the GET body.
What is the correct HTTP method to use when taking data from the client and processing it to generate output?
UPDATE My current thoughts are taking the data in the body of the POST and returning 201 with a LOCATION header containing a GET url that refers to a resource (i.e., Decrypted Metadata). Since the resource itself is not being persisted, I will need to put the metadata as a request parameter in the GET. But since the metadata is limited in length (application limitation), this shouldn't be a problem.
source to share
I would of course avoid using HTTP GET with the request body.
For me, the most appropriate HTTP verb would really be POST. If the resulting resource is not saved, I will not return 201. Also, in your application, this could compromise the decrypted metadata, which will now become a query string parameter. Instead, just return 200 with content, which is perfectly reasonable for a POST operation.
source to share
POST is fine, but don't worry about suggesting a LOCATION header. It's ok to get your metadata back in the body of the POST response with 200 OK.
From RFC :
A POST action 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 the response includes an object that describes the result .
source to share