Re: How to identify existing resource in a POST(a) request

Markus,

Thanks for the response.

With regard to your 'URI per representation' dilemma, this is (as you suggest) a separate problem.

From my perspective, by declaring '.../1.json' and '.../1.xml' two separate resources have been defined.  There is no *need* to define a URI per representation in this manner, as we have 'Content-Type' and 'Accept' headers to deal with that.  The resource is simply '.../1' (or whatever) and it *may* have multiple representations (one per media type).  Irrespective, if a system (designer) chooses to make two (or more) URIs available for the same resource, then they are obliged to manage the 'mapping' of multiple URIs back to the (canonical) resource.  Returning to your example the 'self link' for '.../1.json' should be to '.../1.json' - it's a server responsibility to understand that '.../1.json' maps to resource '1'.  This is not an interface, but an implementation concern.

My question is really regarding whether use of the 'Referer' header is a sensible way to identify the URI of the representation that initiated the request.  Additionally, whilst I note some security concerns in RFC 2616, I see no reference to 'Referer' being restricted to any "last page" notion.  Whilst the "referer as last-page" scenario may an artefact of some web usage patterns, I don't think HTTP constrains it in this way.

Best regards

Paul

On 26 Oct 2012, at 18:50, Markus Lanthaler wrote:

> Paul,
> 
> on the Web resources  are identified by URIs, so that leaves us with your
> options 2 and 3. I don’t really see the problems you outline there but a
> different one. What if a system assigns multiple URLs to access the same
> resource but different representations thereof? For instance
> example.com/persons/1.json and example.com/persons/1.xml? Both return
> representations of the same resource and both would likely contain just
> those URLs in the self-link. So the right link relation to use would be
> canonical [1] and not self. That link can then either be embedded directly
> embedded into the representations or served as an HTTP link header [2].
> Using the referrer won't work as that's the page that a user agent visited
> last which might has nothing to do with that resource it is POSTing.
> 
> Hope this helps,
> Markus
> 
> 
> [1] http://tools.ietf.org/html/rfc6596
> [2] http://tools.ietf.org/html/rfc5988
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler