Re: An IRC discussion with Alexandre Bertails re SSUE-19:

On 6 Jun 2013, at 12:25, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:

> 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.

That is what I keep showing is not the case. Typically you don't do that at all. Those
who use mime types restrictions for RESTful web services are doing something 
else than  what they think they are doing.

> 
> 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...).

When you say: many APIs do not comply with this principle, I put it the other way around, since I don't believe
there to be the principle you refer to. I would say that many APIs seem to apply the principle you 
mention, but that is just a seeming. They are not using media types not to specify the interaction semantics, 
but to specify the type of the content being sent as they should. This is what happened Atom: it is an XML format
and it uses different media types for each xml.  But that is just because XML as atom uses comes without semantics
( There is nor XML Semantics as there is an RDF semantics document ), and so the interpretation of the XML has
to be restrained by a mime type. This is even more the case with JSON which does not have namespaces.

So it is just a mistake to think that any service complies with your principle. IT is a confusion of syntax, semantics
and APIs.  

> 
> 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).

content-negotations should not be used to return different data, since the idea of content
negoation is that you are returning equivalent ( or nearly equivalent ) representations of the
same resource.

> 
> 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).

Perhaps. Not sure. That seems to be too miniamlistic an interpretation of an LDPR.

>  
> > * 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.

exactly. I was going to mention forms too. The issue is exactly the same.

> 
>   pa

Social Web Architect
http://bblfish.net/