If POST to an URL and how can I tell the client to look at a fragment of the response?

Question

I would like to POST an entity as follows

POST /example.org/MyEntity/100

Based on the passed entity, the server would like to draw the users attention to a particular part of the response using a fragment identifier. e.g.

/example.org/MyEntity/100#InterestingPart

How do I return this new URL to the client. I am assuming I could do some form of redirect using a 3XX response code, but I actually do not want the client to do another request because the only difference between the two URLs is the fragment. At the moment it seems that a 307 return code would be the most appropriate because according to the spec you should not automatically redirect a POST.

Is there are better way?

Update: My client is not limited to the constraints of a web browser. I am just looking at this from the perspective of HTTP.

Update2: Based on my reading of RFC2616, I can see nothing stopping me from returning a 200 and a Location header that contains the fragment identifier. Anyone know of a reason why I cannot do that?

Answer 1

I think the only sensible solution is to have action URL have static fragment identifier, like <form method="post" action="/action#anchored"> and then put an anchor wherever you want user to look at while generating page.

But, to answer the Update2: no, there's no reason to avoid it.

Answer 2

You should normally redirect every POST to avoid problems with refreshing the page and the use of the back button. This is known as the PRG (POST Redirect Get) pattern:

http://blog.httpwatch.com/2007/10/03/60-of-web-users-can%E2%80%99t-be-wrong-%E2%80%93-don%E2%80%99t-break-the-back-button/

Although, this does incur the cost of another round trip to the server it makes your web application much more user friendly.

You could then add the fragment onto the redirected URL.

There's an example of PRG with a fragment on this page:

http://www.httpwatch.com/httpgallery/redirection/

Answer 3

My inclination is to return 201 - and have the location header point to the URI you want the client to GET.

I didn't look, but IIRC nothing dictates that the location header points to the resource created, so it should be spec legal.

Answer 4

POSTing to the URI:

http://example.org/MyEntity/100

implies to me that a MyEntity resource called "100" already exists. If that's the case, why not use PUT instead? Is this an update or a create operation?

An alternative might be:

POST http://example.org/MyEntities

Now your service has a choice to make from at least two possibilities:

1. Return 201 Created. Set the Location header to be the URI you want the client to use (e.g.: http://example.org/MyEntities/100#InterestingPart). Add the representation of the new resource to the body.
2. Return 204 No Content. Same as above, but no body. This option requires a subsequent GET to fetch the representation, which sounds like what you're trying to avoid.

Neither approach requires redirection and both can return as specific a URI as you desire.

I am curious though, why is the #InterestingPart significant? Why not just return the entire representation and its URI http://example.org/MyEntities/100 in the Location header - and let clients decide for themselves what's interesting or not? If the answers have something to do with only a small part of the resource being of interest (or being modified) during a request, how feasible would it be to break MyResource into a main resource and one or more subordinate resources? For example:

• /MyResources/100/CoolThings
• /MyResources/100/CoolThings/42
• /MyResources/100/InterestingThings
• /MyResources/100/InterestingThings/109