3 ms·
> Use the HTTP PUT verb to upload your files to the service. Since this is a REST interface, the file will live at the path you specify. Retrieve it with an HTT
by blasdel 16y ago
> Use the HTTP PUT verb to upload your files to the service. Since this is a REST interface, the file will live at the path you specify. Retrieve it with an HTTP GET. You cannot replace existing files. PUTs to existing files will fail with "405 Method Not Allowed".
PUT does not mean what you think it means. The whole point of PUT is that you're replacing an existing resource, which gets you idempotence. You're not supposed to use it to create a resource at the supplied URL, and the whole point is that you can PUT to the same URL repeatedly.
You want POST. Using PUT is making your service less restful.
- mleonhard 16y agoI'm pretty sure I got it right. The HTTP 1.1 RFC says: > The PUT method requests that the enclosed entity be stored under the supplied Request-URI. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 I interpret this to mean that if you PUT to /some/file then you should be able to GET /some/file and get back the same thing. RestBackup access urls provide this behavior.
- blasdel 16y agoSorry, you're right about using PUT to create a resource at the supplied URL -- but you're still breaking the expectation of idempotence: repeating the same request should have the same result, not 201 the first time and 405 thereafter. If you really want those semantics use POST. If you're really set on using PUT, you could change your semantics a bit so that PUTting the original file again results in 200 OK but attempts replace it with a different file return 409 Conflict or something.