On 29 January 2013 07:42, Sebastian Schaffert <[email protected]> wrote: > Hi Sergio, > > thanks for the summary. I agree mostly with your observation. I am trying > to reply to some of the concerns as far as I can: > > 2013/1/28 Sergio Fernández <[email protected]> >> >> >> So here a list of my main questions: >> >> - First of all, fmpov the goal is too high-level defined (see the charter >> [8]), and this derives that it is hard to argue some key decisions, which >> is being conflictive when trying to find agreements with all members. Maybe >> my point of view is too close to my RWW experience, but I guess the current >> protocol is just a meta-protocol with some considerations. >> > > While I agree that it is very high-level, there are fmpov only a few > reasonable ways of implementing the charter, assuming you want to apply the > concepts from Linked Data and REST in a sensible way. Sensible would mean > you respect both, the REST ideas (stateless, POST, PUT, GET, DELETE in > their proper semantics). One of these ways we already implemented (IMHO) in > the web services of the LMF. > > Note that sensible is not always possible, because REST and Linked Data are > not completely aligned in all cases. For example, the HTTP specification > requires that if a client sends a POST or PUT and the server replies with a > 303 redirect, the client should always follow-up with a GET. Which makes it > kind of hard to apply the GET-redirect pattern of Linked Data also to > updates.
I don't think this is a problem with REST. In my opinion, the sem web people caused the issue by creating a new alternative semantics for 303 instead of creating a new 3xx code for their purpose. HTTP 303 was originally specified as a way to give an unrelated redirection link back to a user agent after a successful POST so they had a place to go next, without attaching any semantic link between the 303 resource and the redirect resource. Having a completely different semantic for 303 in response to GET doesn't make sense to me. However, they still retroactively created the extra meaning in recent HTTP RFCs, so you have to support it if you are following the standards. Don't get too many people started on that one though. It is an argument that just goes on and on and never has an end [1]. Cheers, Peter [1] https://en.wikipedia.org/wiki/The_Song_That_Never_Ends
