- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Thu, 6 Jun 2013 12:25:03 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: Alexandre Bertails <bertails@w3.org>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR-bqJ3JpR4MqBYrWCsHgo_nmfexLxy6XHkcj-ZNtAtkMw@mail.gmail.com>
Henry, Alexandre, On Thursday, June 6, 2013, Henry Story wrote: > Well that's my point: mime types are not the place to look > at to find interaction patterns with web resources! That is > not at all what they are designed for. > where then? The whole point of RESTful design (in my understanding) is that you don't need to update your client everytime a new service is available out there. For that, the service has to provide enough information so that the client knows how to "use" it (interaction semantics). Typically, in RESTful design, this interaction semantics is carried by the media-type (e.g. HTML or Atom); by declaring a content-type, the server and the client agree to use an externally defined interaction semantics. True, many web APIs today do not comply with this principle; they provide/consume application/json (or application/xml), and the client has to know which "kind" of JSON can be used with which service. And still, it's working! The question is: would it work better if they did respect REST principles? I believe so (well, depending how you define "better", I guess...). That being said, the point is not, IMHO, about using 'content-type' and only that. I agree that this "externally defined interaction semantics" could be indicated by other means, e.g. the use of some vocabulary inside the media-type. This raises a number of problems, compared with the content-type approach: * you are forced to get and parse the body * you can not do content negociation but I think we can solve that (e.g. with 'profile' Link headers). So I guess I disagree with Alexandre, who seems to think we can not succeed without a new media type. The way I see it, this group is actually *augmenting* the meaning of the Turtle media type (and probably other RDF media-types), by providing it with interaction semantics, captured by the LDP vocabulary. More precisely, to answer Alexandre's questions: > > * how do I know that <foo> is an LDPR? > Well, any resource that yields a Turtle representation becomes de facto an LDPR (even if read-only). > > * how do I know that <foo> is neither an LDPC nor an LDPR? > See above: if it yields Turtle, it *is* and LDPR. (granted, it would be useful to be able to tell the difference btw a read-only and a PUTable LDPR, though) > > * how do I know that I can interact with <foo> using the SPARQL Graph > Protocol? > Is that in our scope? If so, I guess we should have a class or a property to state that about a given resource. > > * if I find out that <foo> a ldp:Container while looking at <bar>, > > should I consider this information as authoritative? > Well, when you find the following HTML <form action="foo" method="foo"> at <bar>, do you believe it? Do you try and perform a POST on <foo>? I guess the answer is the same: if you trust the source, then yes, you're allowed to start interacting with <bar> as if it were an LDPC. pa
Received on Thursday, 6 June 2013 10:25:42 UTC