I'm working on a direct-to-S3 upload service that operates in two parts described below. This service would not be used by browsers, but would be a RESTful API used by other software clients.
Make a request to an endpoint which certifies and validates the upload, returning an upload URL if all's well.
Make a PUT request to the URL returned from #1 to actually do the upload to S3.
How should the server structure the response for the first endpoint?
The first option I am considering would be to use GET and return a status code 302 with a Content-Location header containing the URL to upload to. However, the intent behind the redirect descriptions in the spec seems to be focussed on redirecting after a form submission.
The other option I'm considering is to use POST for the first endpoint and returning a Location header with the URL, as described here:
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header. RFC 2616 #9.5
Please advise on what other people have used in such circumstances?
I think it mainly depends on whether your API itself will have a resource referencing the uploaded file or not. The only one with knowledge of the uploaded file is the S3 itself or your API has something referencing it?
If the first case where only S3 knows about it, then it's OK to use the GET if it acts merely as a generator for the upload parameters, including the URI.
If the second case, then it shouldn't be a GET, since you're changing something on your side. Yes, you should make a POST, but the Location header should be used to return the URI for the created resource that references the uploaded file. That resource may have the upload URI and it could act like a state-machine, tracking if the file is uploaded or not. To avoid the need for clients to GET that resource before being able to upload, you may return the upload URI in the Link header, with a rel reflecting that purpose.
Related
Reading https://developers.google.com/drive/api/v3/reference/files/update I see this comment: "This method supports patch semantics.". Googling around, I can't find any description of the meaning of that phrase neither any hint about how to partially update a Google Drive document. The (diverse) source code I have studied just upload the new version of the file, complete.
Do you know what "patch semantics" means in this context?
Do you know how to partially update a file in google drive without just overwriting it completely?
Thanks!
It means that it is a HTTP PATCH request as opposed to a HTTP PUT request.
The HTTP PATCH request method applies partial modifications to a resource.
VS
The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload.
In the request body, supply the relevant portions of a Files resource, according to the rules of patch semantics.
A PUT would require that you send all of the values and it would update the entire object. Where by a PATCH will only update the parameters you send.
Using the Google drive file update method lets say that you only want to update the file name. Using a PATCH method will allow you to only send the name and only the name would be updated.
However if this was a PUT method every parameter in the object would need to be sent as they will all be updated any parameter that you do not send would then be updated to null.
I've got a problem trying to run a test plan in JMeter which contains a
multipart/form-data POST. For some reason the web server does not respond
with the expected response when JMeter does the POST (which was recorded
with the proxy).
Please tell me the exact configuration to handle it(if any).
As per Upload and Download Scenarios with Apache JMeter guide
Check that “Use multipart/form data for POST” is ticked
Check that files for upload actually exist in their relative location or use the full paths
Provide the correct MIME Type
The combination of above should do the trick for you.
If your file upload assumes authenticated user, make sure that you have HTTP Cookie Manager is present and enabled and in case of any dynamic parameters, like viewstate input value or JSESSIONID cookie you pass them properly. Use a sniffer tool like WireShark to ensure that your request is an exact replica of browser request.
I was working on my server and encountered the need to implement the use of request.headers.referer When I did tests and read headers to determine how to write the parsing functions, I couldn't determine a differentiation between requests that invoke from a link coming from outside the server, outside the directory, or calls for local resources from a given HTML response. For instance,
Going from localhost/dir1 to localhost/dir2 using <a href="http://localhost/dir2"> will yield the response headers:
referer:"http://localhost/dir1" url:"/dir2"
while the HTML file sent from localhost/dir2 asking for resources using local URI style.css will yeild:
referer:"http://localhost/dir2" url:"/style.css"
and the same situation involving an image could end up
referer:"http://localhost/dir2" url:"/_images/image.png"
How would I prevent incorrect resolution, between url and referer, from accidentally being parsed as http://localhost/dir1/dir2 or http://localhost/_images/image.png and so on? Is there a way to tell in what way the URI is being referred by the browser, and how can either the browser or server identify when http://localhost/dir2/../dir1 is intended destination?
Reading this page, it says:
...the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.
From this I gather that I should not have a URL exposed which accepts PUT requests where the URL does not uniquely identify a resource. e.g.:
http://www.example.com/cars
Rather, I should allow PUT requests on the following URL:
http://www.example.com/cars/123
However, in a PUT request, the content is supposed to contain the entire entity, which could, therefore, contain some sort of primary key (like the 123 in the above URL). So is it really considered bad practice to expose non-unique URLs for PUT requests when the content will contain the unique identifier? In my service, all I want to do is collect data from clients, so a RESTful service accepting PUT requrests is great, but I don't really want to have the URL being unique (as this means more work to construct the URL on the client side).
PUT should only be used when the client knows for sure the resulting resource that should contain the entity after the request completes.
If you are simply collecting data from clients, then likely you should be using POST instead.
That is why in REST semantics, the PUT is used for updates and to create any resource you are supposed to be using POST.
While looking at the code in "petclinic", part of Spring 3.0 samples I noticed the following lines
<c:choose>
<c:when test="${owner.new}"><c:set var="method" value="post"/></c:when>
<c:otherwise><c:set var="method" value="put"/></c:otherwise>
</c:choose>
In this discussion at SO it seems that PUT should be used for "create/update" and POST for "updates".
Which is right?
What is the impact of using post for "create" and put for "update"?
Note : According to the HTTP/1.1 spec. quoted in the referenced SO discussion, the code given above seems to have the correct behavior.
Both POST and PUT are have well defined behavior as per HTTP spec.
The result of a POST request should be a new resource that is subordinate to the request URL; the response should contain Location header with the URL of the newly created resource.
The result of a PUT should be an update of the resource at the request URL. if there is no existing resource at the request URL, a new one can be created.
The confusion arises from the fact that POST is also used with forms as a mechanism to pass the form data. Most common implementation of forms is to post back to the same URL at which the form page is located, thus giving the false idea that the POST operation is used for an update. However, in this particular usage, the form page is not the resource.
With all this in mind, here's the correct (in my opinion of course :-)) usage:
POST should be used to create new resources when:
- the new resource is subordinate to an existing resource
- the resource identity/URL is not known at creation time
PUT should be used to update existing resources with well-known URL. It can be used to create a resource at well-known URL as well; however, it does help to think about this scenario in a different way - if the resource URL is known before the PUT request is made, this could be treated the same as the resource at this location already existing but being empty.
It's quite simple:
POST allows anything to happen, and it isn't restricted to creating "subordinate" resources, but allows the client to "provide a block of data ... to a data-handling process" (RFC 2616 sec 9.5). POST means "Here's that data you asked for just now"
PUT is used as an opposite of GET. The usual flow is that you GET a resource, modify it somehow, and then you PUT it back at the same URI that you got it from. PUT means "Please store this file at this URI".
The uniformity of PUT (which is to store a file) allows intermediaries (e.g. caches) to invalidate any cached responses they might have at that exact URI (since they know that it's about to change). The uniformity of PUT also allows clients (that understand this) to modify a resource by first retrieving it (GET) and then send a modified copy back (PUT). It also allows clients to retry on a network failure, due to PUT's idempotency.
Side note: Using PUT to create resources is dubious. While it's possible within the spec, I don't see it as a good idea, just as using POST to perform searches isn't a good idea, just as tunneling SOAP over HTTP isn't a good idea. AtomPub explicitly states that PUT isn't used to create atom entries.
POSTs ubiquitousness comes from the fact that HTML defines <form> elements that result in POSTing a application/x-www-form-urlencoded entity, with which the recipient can do anything it pleases, including
creating subordinate resources (The repsonse is usually accompanied by a 201 response and Location header)
creating a completely different resource (again usually a 201 response and Location header)
creating many subordinate and/or unrelated resources (perhaps with a simple response indicating the URIs of the created resources)
doing nothing except return a response (e.g. 200 or 302) (a case where perhaps GET should have been used)
modifying the resource that received the POST itself (returning or redirecting back to the updated resource).
delete one or more resource.
any combination of the above.
The only one who knows what will happen in a POST request is the user who initiated the request (by clicking the huge "yes I confirm deleting my Facebook profile" button) and the server that's handling the request. To the rest of the world, the request is opaque and doesn't mean anything other than "this URI is being passed some data".
So the answer to your question is that both POST and PUT can be used for both create and update.
POST is often use to create resources (like AtomPub 9.2)
PUT semantics fits well for modifying resources (like AtomPub 9.3)
POST may be used to modify resources (like a www form edit your profile)
PUT can technically be used to create resources (although I advise against it)