Re: LDP would benefit from being RESTful

hello mark.

thanks a lot for your feedback!

On 2012-11-14 9:05 , Mark Baker wrote:
> The charter of the WG mentions the word "REST" at least a dozen times,
> yet the specification is rife with normative text that is explicitly
> not RESTful. I've previously pointed out one specific case[1], but
> there are others, though I think it would also be counter-productive
> to itemize those at this time. That is because they all seem to stem
> from a belief - hardwired in the editorial style of the specification
> - that you're specifying a protocol at the layer of HTTP. IMO, you
> shouldn't, and instead should be focusing on standardizing terms and
> describing best practices; vocabularies, not conformance criteria.

i agree that from the REST perspective, a lot of things are not what 
most people from the REST side of things would be doing this way. i 
things the main problem here is that REST can have at least three layers 
of meaning (and probably more), as we try to make very clearly in any 
REST intro that we've done in the past...

http://dret.net/netdret/docs/rest-icwe2010/rest#%284%29

what most of the REST community has converged on is view number two in 
this list: when referring to REST, you're not actually referring to REST 
as the abstract architectural style (which is what it actually is, 
technically speaking), and you're also not referring to doing whatever 
you want to do redefining what peers have to do when they use HTTP. what 
you do is you use the set of available web architectural elements (HTTP, 
representations, media types, stateless interactions) using the web as a 
platform. i think this is a useful interpretation of the term "REST" to 
converge on, and i'd argue that most of the REST community has done that 
(but it took a while).

on the other hand, when you google "REST API" or similar terms, most of 
the things you'll find that are labeled as "REST" aren't really RESTful 
at all. this term has been watered down to just meaning "we dumped SOAP 
because nobody wants it anymore, and now we do the same things through 
HTTP, but still our way."

the problem with "making LDP RESTful" (according to the definition you 
refer to and the definition i was referring to above) is that RDF isn't 
RESTful it itself because it's not a hypermedia format. and we as a 
group cannot change this (it is way outside what we're chartered to do), 
this is just a limitation of the current state of affairs with RDF. this 
means that yes, we have to define vocabularies (as you say), but what we 
would need to do is define media types, which are a mix of data 
vocabularies (the representations) and interaction vocabularies (the 
affordances in representations provided by links). what you are asking 
us is to do this latter thing, and it would be great if we could do 
this, but unless we define our own framework for turning RDF into a 
hypermedia format, i have a hard time imagining how we could do it cleanly.

what you want us to do (i think) is to define a vocabulary in hyperRDF 
(i just made that up) that clearly defines both the representations we 
are designing interactions around, and the links that can be used by any 
hyperRDF-aware client to identify the interaction affordances provided 
in those representations. if that's what you want, then i agree that 
this would be the way to go, but sadly, there is no hyperRDF. am i 
interpreting correctly what you would like us to do? and if yes, given 
that there is no hyperRDF, what would you like us to do?

cheers,

dret.

Received on Wednesday, 14 November 2012 18:29:17 UTC