TL;DR - use PUT /files/{id}
with the content in the body.
What this depends on is - what is the (unique to your system) identity of a File
? I'll assume here that it's the Id
passed in by the client, and that Path
is simply metadata. If path forms part of the identity as well, you'll need to adjust this accordingly.
As it's the client that supplies and determines the identity, you should probably prefer a PUT
to a POST
, and supply the identity in the path; e.g. PUT /files/{id}
with the path and content in the body. A subsequent identical PUT
leaves the system in the identical state, so it satisfies the requirement that a PUT
is idempotent to observers. A subsequent non-identical PUT
updates the existing content.
The HTTP spec allows some flexibility here, so you can use a POST
. The latest has changed the definition of POST
a little (to have broader application), but in the original (emphasis mine)...
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
... it was clearer that POST /files
makes sense to create e.g. a file in a directory (their example), but POST /files/{id}
makes less sense.
This discussion has some more on PUT vs POST. It's also asserted there that:
Note that the following is an error:
POST /questions/<new_question> HTTP/1.1
Host: www.example.com/
If the
URL is not yet created, you should not be using POST to create it
while specifying the name. This should result in a 'resource not
found' error because <new_question> does not exist yet. You should PUT
the <new_question> resource on the server first.