Re: [web-annotation] avoid constraining HTTP

LDP does not weasle, it's doing things right. i put quite a bit effort
 into trying to explain to the group that instead of defining a new 
protocol (and thus tightly couple clients and servers speaking that 
particular dialect), a much better way to go is to use HTTP as the 
application protocol. that's pretty much all what REST in its web 
flavor is about. clients shouldn't make any server-specific 
assumptions or have to know about them. if you're going this way, 
you're losing the webbyness of the web. simply document the concepts 
that clients should now about (media types, header fields, link 
relations, and so forth), and that's your "protocol".
https://github.com/dret/sedola is the (admittedly pretty incomplete so
 far) attempt to support this style of "service description": it 
allows services to publish inventories of web-level concepts (so far: 
media types, header fields, link relations), and that's all that's 
needed. the protocol *is* HTTP.
if you want to publish best practices for implementations, that's a 
different thing, and then you can say that implementations SHOULD 
always add "Allow", because that's a nice thing to do. but that's a 
very different thing from defining a protocol that's defining the 
rules that clients and servers must live by, or things will break.
and as i said, you don't get anything out of this anyway, other than 
tight coupling and brittleness. clients still have to deal with 405, 
since by definition there is nothing bigger in scope than a single 
request/response interaction. clients still have to assume that in 
between receiving an "Allow", and sending a request using a listed 
method, the server may have changed its mind and no longer support the
 method. you simply cannot change this aspect of HTTP.

-- 
GitHub Notif of comment by dret
See 
https://github.com/w3c/web-annotation/issues/51#issuecomment-119326981

Received on Tuesday, 7 July 2015 20:29:51 UTC