W3C home > Mailing lists > Public > public-annotation@w3.org > July 2015

Re: [web-annotation] avoid constraining HTTP

From: Erik Wilde via GitHub <sysbot+gh@w3.org>
Date: Thu, 09 Jul 2015 17:27:23 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-120079220-1436462842-sysbot+gh@w3.org>
HTTP defines this as a MAY. therefore that's all that clients can 
expect in an HTTP world. expecting more leads to bad clients that 
break in an HTTP world because developers will take shortcuts and 
write code that incorrectly assumes that taking `Allow` as a promise 
is a reasonable thing to do. HTTP says that whatever methods a 
resource supports MAY be exposed via `Allow`, and that's enough. there
 is no way how clients can depend on this information anyway, they 
still have to be coded in a way that can deal with 405 responses. if 
you encourage clients to do something else, you encourage the 
development of broken clients.
it's like @azaroth42 said, in theory the "protocol" could simply point
 to HTTP, and that's all that would be required. in practice, it can 
be helpful to have a document that explains everything in context, so 
that developers can understand which concepts of HTTP, which media 
types, and which additional aspects of the web they should take into 
account when dealing with the specific service. but that's really not 
more than a convenience, because in the end, all of the moving parts 
in the service need to be specified somewhere (media types including 
processing models and so forth), and putting those in context in a 
single document is simply helpful.
as a side note: personally, i have started calling the media type the 
protocol, because it defines the ways in which peers have to process 
and understand data, and in which they can engage in protocol 
conversations (by following links). this is not entirely correct, 
because technically speaking, HTTP is the actual application protocol 
(and the only thing that is required to engage in successful 
individual interactions), but it is the protocol at a slightly higher 
level when it comes to conversations that go beyond single 
request/response interactions, and talking about how clients might 
want to achieve certain application goals.

GitHub Notif of comment by dret
Received on Thursday, 9 July 2015 17:27:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC