Re: Accept on GET and access control

hello henry.

On 2014-01-13, 19:15 , "Henry Story" <henry.story@bblfish.net> wrote:
>So here of course the Allow: header described in 4.9 should come in
>useful, which section 4.3.1 specifies MUST also be present in GET [4].
>I expect here that when a response specifies something like

in a pure REST design, it's kind of odd to say that such a header MUST be
present. HTTP does not say it's mandatory (unless you're sending a 405
response), so it is not mandatory. given that it's nothing more than a
hint, it probably also does not make a lot of sense to make it mandatory.
i am saying this because:

- nothing keeps a client from trying all kinds of methods on a resource,
and seeing what happens. that's simply what HTTP allows and is good at:
context-free interactions with resources.

- even if some context has been provided in previous responses (such as
Allow:), it may change between the time when the response was received,
and when a subsequent request is sent. so the Allow: information always is
a non-binding hint, and what matters is the runtime behavior.

RFC 2616: "This field cannot prevent a client from trying other methods.
However, the indications given by the Allow header field value SHOULD be
followed. The actual set of allowed methods is defined by the origin
server at the time of each request."
http://tools.ietf.org/html/rfc2616#section-14.7


http://tools.ietf.org/html/draft-wilde-link-desc-00 is something i've been
working on for a while now, and i know that it's not as polished as it
should be. it results from two use cases:

- http://tools.ietf.org/html/draft-nottingham-json-home-03 is essentially
a format for publishing some resource hints, intended for initial
consumption by a client that wants to start interacting with a service.
link descriptions are an attempt to make this format a bit more reusable,
so that a resource's capabilities can not only be described in a home
document, but essentially in *any link* that's linking to such a resource.

- in our products, we have many places where interactions are highly
contextual, i.e. they depend on the identity of the client and the
associated authorization. link descriptions are intended to be the general
design pattern how we make this information available, and not just for
things such as HTTP methods, but also for more advanced information such
as value ranges of URI template variables. we need this descriptive power
so that clients can for example drive UI composition off of that ("i know
that when requesting pages for this collection, i can request pages 1 to
42"), but this may be entirely out of scope for what you're trying to do.

cheers,

dret.

Received on Tuesday, 14 January 2014 08:32:22 UTC