Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Re: Media Type Version Negotiation

Expand Messages
  • Noah Campbell
    What do you mean by complete payload semantics? In the case of xhtml, the semantics of the document are that you scan the document, build context by reading
    Message 1 of 43 , Sep 14, 2009
    • 0 Attachment
      What do you mean by complete payload semantics?  In the case of xhtml, the semantics of the document are that you scan the document, build context by reading or looking for a particular token (in my example this would be a rel tag if the agent is autonomous) and follow a link.  How an agent searches a document is unique to that agent.

      The same goes for application/xml, it just folks want to have it bind to a schema so the tools know who to consume the document in its entirety.  This is brittle since the serialization techniques rely on a very concise definition of the payload.  Anything out of the ordinary causes an exception or error.

      -Noah

      On Mon, Sep 14, 2009 at 5:19 AM, Mike Kelly <mike@...> wrote:
      Jan Algermissen wrote:

      The content type header should express the complete payload semantics,  otherwise understanding the payload is dependent on out of band  information which creates unnecessary coupling and limits the  visibility (e.g. for intermediaries).
       

      If you are contrasting a *custom* content-type parameter with a custom version header, I don't agree there is more coupling or less visibility with the latter.

      In fact, intermediary mechanisms would seem better off if the version is a separate header in its own right; e.g. the vary mechanism (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44)

      - Mike

    • Peter Keane
      ... Just a bit of a side note.... In my experience, *not* using PUT and DELETE is unnecessary. If we keep overloading/misusing POST, we re just creating a
      Message 43 of 43 , Sep 21, 2009
      • 0 Attachment
        On Mon, Sep 21, 2009 at 9:53 AM, Subbu Allamaraju <subbu@...> wrote:
        >
        >
        >
        > > The excuse that RESTful systems can't use media-type versioning
        > > because some web browsers don't deliver the right accept header is
        > > bogus because if we are going to dictate restful architectures based
        > > on existing client behaviour then we had better toss out PUT and
        > > DELETE too. Sure there will be some systems where this is a deal
        > > breaker, but that needs to be decided on a case by case basis.
        >
        > Yes, we continue to toss out PUT and DELETE for web apps. What's the
        > point of an architecture if all tradeoffs are ignored? REST is not a
        > non-negotiable style.

        Just a bit of a side note.... In my experience, *not* using PUT and
        DELETE is unnecessary. If we keep overloading/misusing POST, we're
        just creating a messy eco-system for REST. I've had no problem with
        any of the major browsers "hijacking" a form to perfom a real http
        DELETE using a touch of javascript/xhr. Same for PUT -- if you have a
        template generating your html, the "action" attribute of the form can
        quite easily be the actual URI of the resource being edited. Then a
        simply myform.onsubmit = function() { ajaxlib.ajax( this.action,'PUT',
        this.serialize_as_atom()) }.

        I think it makes for a better RESTful interface, and all of the other
        tools I use to interact w/ the app (CURL or whatever), work just as
        I'd hope.

        If I need/want to stay in the browser for testing and such, There's
        Firebug to trace all of this XHR HTTP and plugins like Poster which
        allow me to do any HTTP interaction (w/ all 4 verbs).

        --peter

        >
        > When all the media types are application specific (i.e. custom), and
        > all bits of the infrastructure can deal with it those media types,
        > then media type based versioning works just fine. But these conditions
        > don't hold good always.
        >
        > > Out of curiosity, do you have pointers to the scenarios where URI
        > > based versioning has worked well. I would be interested to compare
        > > the contexts.
        >
        > Sorry, I don't have one on the public internet.
        >
        > Subbu
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.