Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm developing a RESTful service. Here is a map of the current feature set:

POST /api/document/file.jpg    (creates the resource)
GET /api/document/file.jpg     (retrieves the resource)
DELETE /api/document/file.jpg  (removes the resource)

So far, it does everything you might expect. I have a particular use case where I need to set up the browser to send a POST request using the multipart/form-data encoding for the document upload but when it is completed I want to redirect them back to the form. I know how to do a redirect, but I'm not certain about how the client and server should negotiate this behavior. Two approaches I'm considering:

  1. On the server check for the multipart/form-data encoding and, if present, redirect to the referrer when the request is complete.
  2. Add a service URI of /api/document/file.jpg/redirect to redirect to the referrer when the request is complete.

I looked into setting an X header (X-myapp-redirect) but you can't tell the browser which headers to use like this. I manage the code for both the client and the server side so I'm flexible on solutions here. Is there a best practice to follow here?

share|improve this question
1  
First - the create should probably be a PUT, not poas POST. Also not clear on what the POST is doing with its multipart upload, can you elaborate? Any why go back to the form anyways - what is the purpose of that? –  sdg Apr 30 '12 at 16:16
    
The POST request is sending a document from client using a form upload. I agree about PUT, but the jury is somewhat out on browser support there. The use case is returning to the form with a flash message with a response status. –  Duane Gran Apr 30 '12 at 16:35

1 Answer 1

This sounds like a pretty classic case of POST/Redirect/GET, and is sort of the expected behavior for web applications. I'd probably make that the default.

If you're not a fan of that approach for whatever reason, consider using AJAX (which means you can use the PUT approach mentioned by @sdg in a comment) with a standard 201 and the response body can contain the flash message to be displayed. The AJAX can do what you need it to do with the flash message, at that point.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.