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

Self descriptiveness issues with general media types?

Expand Messages
  • Jan Algermissen
    On thing that keeps bugging me.... Suppose I have an order accepting resource /order-processor-a and the client has discovered that it accepts
    Message 1 of 12 , Oct 29, 2009
      On thing that keeps bugging me....

      Suppose I have an order accepting resource /order-processor-a and the
      client has discovered that it accepts application/order+xml (assuming
      the type being a standard type). Order submissions would be done with

      (Case A:)

      POST /order-processor-a
      Content-Type: application/order+xml

      <order>
      <item>A</item>
      <item>B</item>
      </order>

      Now suppose I had another order processor that accepts submission of
      orders in the form of form data, e.g.


      (Case B:)

      POST /order-processor-b
      Content-Type: application/x-www-form-urlencoded

      item=A&item=B


      Isn't case B violating REST's message self descriptiveness constraint
      because the meaning of the message depends on the knowledge that the
      recipient is an order processor? IOW, an observer could only figure
      out the meaning if it knew the past interactions and not form the
      message itself.

      Is application/x-www-form-urlencoded as bad a choice as application/
      xml? In fact, is any general media type (e.g. text/uri-list) a
      violation of the message self descriptiveness constraint?

      Thanks,

      Jan
    • mike amundsen
      Jan: If I understand your post, I think you might be assuming that the self-descriptive part refers to the body of the message. Here s a couple things for
      Message 2 of 12 , Oct 29, 2009
        Jan:

        If I understand your post, I think you might be assuming that the
        "self-descriptive" part refers to the body of the message.

        Here's a couple things for you to consider.

        1 - self-descriptive messages are ones that "stand-alone"; are not
        dependent on previous or subsequent messages exchanged between
        parties.

        2 - the "message" is not just the body, it's the entire _message_ including
        + the operation + URI (POST /order-processor-a)
        +the control data (all the header information)
        + the entity body (actual representation sent)

        If the server announces that it understands the
        application/x-www-form-urlencoded media-type for the /process-order-b
        resource and the client also understands that media-type, that is all
        that is needed. It might be necessary for clients and servers to
        exchange additional out-of-band information on the proper way to form
        the message for a particular media type (element names, order, etc.),
        but that descriptive information is something else.

        Finally, the details of the entity body are only interesting to the
        two parties involved in the message (sender, receiver). From the
        intermediaries POV, they need to no nothing about this body - in fact
        should not be peeking into the body at all.

        mca
        http://amundsen.com/blog/




        On Thu, Oct 29, 2009 at 09:34, Jan Algermissen <algermissen1971@...> wrote:
        > On thing that keeps bugging me....
        >
        > Suppose I have an order accepting resource /order-processor-a and the
        > client has discovered that it accepts application/order+xml (assuming
        > the type being a standard type). Order submissions would be done with
        >
        > (Case A:)
        >
        > POST /order-processor-a
        > Content-Type: application/order+xml
        >
        > <order>
        >   <item>A</item>
        >   <item>B</item>
        > </order>
        >
        > Now suppose I had another order processor that accepts submission of
        > orders in the form of form data, e.g.
        >
        >
        > (Case B:)
        >
        > POST /order-processor-b
        > Content-Type: application/x-www-form-urlencoded
        >
        > item=A&item=B
        >
        >
        > Isn't case B violating REST's message self descriptiveness constraint
        > because the meaning of the message depends on the knowledge that the
        > recipient is an order processor? IOW, an observer could only figure
        > out the meaning if it knew the past interactions and not form the
        > message itself.
        >
        > Is application/x-www-form-urlencoded as bad a choice as application/
        > xml? In fact, is any general media type (e.g. text/uri-list) a
        > violation of the message self descriptiveness constraint?
        >
        > Thanks,
        >
        > Jan
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
      • Subbu Allamaraju
        As far as the protocol is concerned, a message using general purpose media types is still self-descriptive. For instance, HTTP does not depend on the meaning
        Message 3 of 12 , Oct 29, 2009
          As far as the protocol is concerned, a message using general purpose
          media types is still self-descriptive. For instance, HTTP does not
          depend on the meaning of a application/x-www-form-urlencoded body of a
          message. As far HTTP and intermediaries are concerned, that media type
          is just an identifier for the format of the message.

          Subbu

          On Oct 29, 2009, at 6:34 AM, Jan Algermissen wrote:

          > On thing that keeps bugging me....
          >
          > Suppose I have an order accepting resource /order-processor-a and the
          > client has discovered that it accepts application/order+xml (assuming
          > the type being a standard type). Order submissions would be done with
          >
          > (Case A:)
          >
          > POST /order-processor-a
          > Content-Type: application/order+xml
          >
          > <order>
          > <item>A</item>
          > <item>B</item>
          > </order>
          >
          > Now suppose I had another order processor that accepts submission of
          > orders in the form of form data, e.g.
          >
          >
          > (Case B:)
          >
          > POST /order-processor-b
          > Content-Type: application/x-www-form-urlencoded
          >
          > item=A&item=B
          >
          >
          > Isn't case B violating REST's message self descriptiveness constraint
          > because the meaning of the message depends on the knowledge that the
          > recipient is an order processor? IOW, an observer could only figure
          > out the meaning if it knew the past interactions and not form the
          > message itself.
          >
          > Is application/x-www-form-urlencoded as bad a choice as application/
          > xml? In fact, is any general media type (e.g. text/uri-list) a
          > violation of the message self descriptiveness constraint?
          >
          > Thanks,
          >
          > Jan
          >
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Craig McClanahan
          In addition to the good comments you ve already received from Mike and Subbu, one other detail to consider is this: you do not *have* to use different URIs
          Message 4 of 12 , Oct 29, 2009
            In addition to the good comments you've already received from Mike and Subbu, one other detail to consider is this:  you do not *have* to use different URIs for order processing in order to process two different media types.  It is also reasonable to have the same URI handle both (presumably doing a media type specific conversion to internal data structures, followed by common processing that doesn't care what the incoming format was).

            Craig McClanahan

            On Thu, Oct 29, 2009 at 6:34 AM, Jan Algermissen <algermissen1971@...> wrote:
             

            On thing that keeps bugging me....

            Suppose I have an order accepting resource /order-processor-a and the
            client has discovered that it accepts application/order+xml (assuming
            the type being a standard type). Order submissions would be done with

            (Case A:)

            POST /order-processor-a
            Content-Type: application/order+xml

            <order>
            <item>A</item>
            <item>B</item>
            </order>

            Now suppose I had another order processor that accepts submission of
            orders in the form of form data, e.g.

            (Case B:)

            POST /order-processor-b
            Content-Type: application/x-www-form-urlencoded

            item=A&item=B

            Isn't case B violating REST's message self descriptiveness constraint
            because the meaning of the message depends on the knowledge that the
            recipient is an order processor? IOW, an observer could only figure
            out the meaning if it knew the past interactions and not form the
            message itself.

            Is application/x-www-form-urlencoded as bad a choice as application/
            xml? In fact, is any general media type (e.g. text/uri-list) a
            violation of the message self descriptiveness constraint?

            Thanks,

            Jan


          • wahbedahbe
            ... Is that out-of-band info allowed from a REST perspective? I ve always assumed that constraints on a general media types must be communicated in
            Message 5 of 12 , Nov 2, 2009
              --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
              > If the server announces that it understands the
              > application/x-www-form-urlencoded media-type for the /process-order-b
              > resource and the client also understands that media-type, that is all
              > that is needed. It might be necessary for clients and servers to
              > exchange additional out-of-band information on the proper way to form
              > the message for a particular media type (element names, order, etc.),
              > but that descriptive information is something else.
              >

              Is that out-of-band info "allowed" from a REST perspective? I've always assumed that constraints on a general media types must be communicated in hypermedia (just like the URI). In other words, you need something like a <form>. Is that not the case?

              Though I suppose the "form" constraints could also be fixed. ie. the definition of application/orderform+xml describes the constraints on application/x-form-urlencoded requests so no run-time info is needed. Still, the available choices are a) something specific in the definition of the media type(s) or b) something communicated at run-time in hypermedia (or a combination of a and b). Make sense?


              > Finally, the details of the entity body are only interesting to the
              > two parties involved in the message (sender, receiver). From the
              > intermediaries POV, they need to no nothing about this body - in fact
              > should not be peeking into the body at all.

              Is that actually a constraint? Some protocols, like SIP, place explicit restrictions on what a proxy can do with the body. But I wasn't aware of anything in HTTP that restricted the proxy behavior this way -- and I can't think of a REST constraint on this.

              Regards,

              Andrew
            • mike amundsen
              Andrew: good points: I ve always assumed that constraints on a general media types must be communicated in hypermedia (just like the URI). By
              Message 6 of 12 , Nov 2, 2009
                Andrew:

                good points:
                <snip>
                I've always assumed that constraints on a general media types must be
                communicated in hypermedia (just like the URI).
                </snip>
                By "general media types" are you thinking there are "non-general"
                media types that may not require constraints (on inputs, I assume) be
                communicated via hypermedia?

                <snip>
                But I wasn't aware of anything in HTTP that restricted the proxy
                behavior this way -- and I can't think of a REST constraint on this.
                </snip>

                I have in mind the following from Fielding:
                "REST enables intermediate processing by constraining messages to be
                self-descriptive: interaction is stateless between requests, standard
                methods and media types are used to indicate semantics and exchange
                information, and responses explicitly indicate cacheability." [1]

                I have adopted an interpretation of this section that closely follows
                that described by Joe Gregorio:
                "...[T]he reason that RESTful systems can scale much easier ... has to
                do with the amount of information that each message carries and that
                is available to intermediaries without peeking into the body." [2]

                I find no direct references to "not peeking into the body" in Fielding
                or RFC2616.

                mca
                http://amundsen.com/blog/

                [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_1
                [2] http://bitworking.org/news/125/REST-and-WS#self-descriptive


                On Mon, Nov 2, 2009 at 13:51, wahbedahbe <andrew.wahbe@...> wrote:
                > --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                >> If the server announces that it understands the
                >> application/x-www-form-urlencoded media-type for the /process-order-b
                >> resource and the client also understands that media-type, that is all
                >> that is needed. It might be necessary for clients and servers to
                >> exchange additional out-of-band information on the proper way to form
                >> the message for a particular media type (element names, order, etc.),
                >> but that descriptive information is something else.
                >>
                >
                > Is that out-of-band info "allowed" from a REST perspective? I've always assumed that constraints on a general media types must be communicated in hypermedia (just like the URI). In other words, you need something like a <form>. Is that not the case?
                >
                > Though I suppose the "form" constraints could also be fixed. ie. the definition of application/orderform+xml describes the constraints on application/x-form-urlencoded requests so no run-time info is needed. Still, the available choices are a) something specific in the definition of the media type(s) or b) something communicated at run-time in hypermedia (or a combination of a and b). Make sense?
                >
                >
                >> Finally, the details of the entity body are only interesting to the
                >> two parties involved in the message (sender, receiver). From the
                >> intermediaries POV, they need to no nothing about this body - in fact
                >> should not be peeking into the body at all.
                >
                > Is that actually a constraint? Some protocols, like SIP, place explicit restrictions on what a proxy can do with the body. But I wasn't aware of anything in HTTP that restricted the proxy behavior this way -- and I can't think of a REST constraint on this.
                >
                > Regards,
                >
                > Andrew
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Jan Algermissen
                ... My understanding is that when a spec tells you that some URI you find in some hypermedia context (e.g. as link target with a certain relation) it is
                Message 7 of 12 , Nov 2, 2009
                  On Nov 2, 2009, at 7:51 PM, wahbedahbe wrote:

                  > --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                  >> If the server announces that it understands the
                  >> application/x-www-form-urlencoded media-type for the /process-order-b
                  >> resource and the client also understands that media-type, that is all
                  >> that is needed. It might be necessary for clients and servers to
                  >> exchange additional out-of-band information on the proper way to form
                  >> the message for a particular media type (element names, order, etc.),
                  >> but that descriptive information is something else.
                  >>
                  >
                  > Is that out-of-band info "allowed" from a REST perspective? I've
                  > always assumed that constraints on a general media types must be
                  > communicated in hypermedia (just like the URI). In other words, you
                  > need something like a <form>. Is that not the case?

                  My understanding is that when a spec tells you that some URI you find
                  in some hypermedia context (e.g. as link target with a certain
                  relation) it is allowed to establish enay kind of contract between
                  client(you) and server. What matter is that you discovered the URI
                  from hypermedia and that the spec defines which assumptions the client
                  can make.

                  Of course the use of forms increases flexibility.

                  Jan


                  >
                  > Though I suppose the "form" constraints could also be fixed. ie. the
                  > definition of application/orderform+xml describes the constraints on
                  > application/x-form-urlencoded requests so no run-time info is
                  > needed. Still, the available choices are a) something specific in
                  > the definition of the media type(s) or b) something communicated at
                  > run-time in hypermedia (or a combination of a and b). Make sense?
                  >
                  >
                  >> Finally, the details of the entity body are only interesting to the
                  >> two parties involved in the message (sender, receiver). From the
                  >> intermediaries POV, they need to no nothing about this body - in fact
                  >> should not be peeking into the body at all.
                  >
                  > Is that actually a constraint? Some protocols, like SIP, place
                  > explicit restrictions on what a proxy can do with the body. But I
                  > wasn't aware of anything in HTTP that restricted the proxy behavior
                  > this way -- and I can't think of a REST constraint on this.
                  >
                  > Regards,
                  >
                  > Andrew
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >

                  --------------------------------------
                  Jan Algermissen

                  Mail: algermissen@...
                  Blog: http://algermissen.blogspot.com/
                  Home: http://www.jalgermissen.com
                  --------------------------------------
                • Roy T. Fielding
                  ... Er, in terms of REST, that is not a style issue. In HTTP, it is kind of obvious, so I didn t think to write it down. You would have to look in the
                  Message 8 of 12 , Nov 2, 2009
                    On Nov 2, 2009, at 11:39 AM, mike amundsen wrote:

                    > Andrew:
                    >
                    > good points:
                    > <snip>
                    > I've always assumed that constraints on a general media types must be
                    > communicated in hypermedia (just like the URI).
                    > </snip>
                    > By "general media types" are you thinking there are "non-general"
                    > media types that may not require constraints (on inputs, I assume) be
                    > communicated via hypermedia?
                    >
                    > <snip>
                    > But I wasn't aware of anything in HTTP that restricted the proxy
                    > behavior this way -- and I can't think of a REST constraint on this.
                    > </snip>
                    >
                    > I have in mind the following from Fielding:
                    > "REST enables intermediate processing by constraining messages to be
                    > self-descriptive: interaction is stateless between requests, standard
                    > methods and media types are used to indicate semantics and exchange
                    > information, and responses explicitly indicate cacheability." [1]
                    >
                    > I have adopted an interpretation of this section that closely follows
                    > that described by Joe Gregorio:
                    > "...[T]he reason that RESTful systems can scale much easier ... has to
                    > do with the amount of information that each message carries and that
                    > is available to intermediaries without peeking into the body." [2]
                    >
                    > I find no direct references to "not peeking into the body" in Fielding
                    > or RFC2616.

                    Er, in terms of REST, that is not a style issue. In HTTP, it is
                    kind of obvious, so I didn't think to write it down. You would
                    have to look in the http-wg archives to see all the discussion about
                    why length-delimited framing is better than MIME-style boundaries.

                    ....Roy
                  • Andrew Wahbe
                    ... Fair enough, but the fact that self-descriptive messages enable efficient processing by intermediaries is one thing; and asserting that intermediaries
                    Message 9 of 12 , Nov 2, 2009
                      On Mon, Nov 2, 2009 at 7:27 PM, Roy T. Fielding <fielding@...> wrote:
                      > On Nov 2, 2009, at 11:39 AM, mike amundsen wrote:
                      >
                      >> Andrew:
                      >>
                      >> good points:
                      >> <snip>
                      >> I've always assumed that constraints on a general media types must be
                      >> communicated in hypermedia (just like the URI).
                      >> </snip>
                      >> By "general media types" are you thinking there are "non-general"
                      >> media types that may not require constraints (on inputs, I assume) be
                      >> communicated via hypermedia?
                      >>
                      >> <snip>
                      >> But I wasn't aware of anything in HTTP that restricted the proxy
                      >> behavior this way -- and I can't think of a REST constraint on this.
                      >> </snip>
                      >>
                      >> I have in mind the following from Fielding:
                      >> "REST enables intermediate processing by constraining messages to be
                      >> self-descriptive: interaction is stateless between requests, standard
                      >> methods and media types are used to indicate semantics and exchange
                      >> information, and responses explicitly indicate cacheability." [1]
                      >>
                      >> I have adopted an interpretation of this section that closely follows
                      >> that described by Joe Gregorio:
                      >> "...[T]he reason that RESTful systems can scale much easier ... has to
                      >> do with the amount of information that each message carries and that
                      >> is available to intermediaries without peeking into the body." [2]
                      >>
                      >> I find no direct references to "not peeking into the body" in Fielding
                      >> or RFC2616.
                      >
                      > Er, in terms of REST, that is not a style issue.  In HTTP, it is
                      > kind of obvious, so I didn't think to write it down.  You would
                      > have to look in the http-wg archives to see all the discussion about
                      > why length-delimited framing is better than MIME-style boundaries.
                      >
                      > ....Roy
                      >

                      Fair enough, but the fact that self-descriptive messages enable
                      efficient processing by intermediaries is one thing; and asserting
                      that intermediaries "should not be peeking inside the body at all" is
                      another. I questioned the assertion because it is not uncommon to see
                      gateway proxies mucking about in bodies, rewriting URIs etc.And while
                      this is often criticized for all the obvious reasons, I wasn't aware
                      of any well-defined rule that was being violated. SIP contains
                      language like "The proxy MUST NOT add to, modify, or remove the
                      message body." so that sort of proxy behavior would be a violation of
                      the protocol. I assumed that HTTP didn't contain this sort of language
                      because it was overly restrictive (e.g. if you must resort to
                      something like URI rewriting then you can as long as you are prepared
                      to deal with the costs). Is this not the case?

                      Also, I'm curious as to why this couldn't be a style issue. The
                      closest thing I've found to architectural style-like constraints for
                      the SIP architecture is Rosenberg's Architecture and Design Principles
                      for SIP (http://tools.ietf.org/html/draft-rosenberg-sipping-sip-arch-01).
                      It describes the "Proxies are for routing" principle which assigns a
                      specific role to intermediaries -- similar to the roles assigned by
                      the client-server constraint. One might argue that the SIP protocol
                      constraint quoted above is derived from this principle. Is there some
                      reason that an architectural style couldn't or shouldn't contain a
                      constraint that implies that intermediaries never modify message
                      bodies?

                      Regards,

                      Andrew
                    • Roy T. Fielding
                      ... You lost me there. I thought you were talking about not looking inside the body for performance reasons. HTTP is designed so that an intermediary doesn t
                      Message 10 of 12 , Nov 2, 2009
                        On Nov 2, 2009, at 10:07 PM, Andrew Wahbe wrote:
                        > Fair enough, but the fact that self-descriptive messages enable
                        > efficient processing by intermediaries is one thing; and asserting
                        > that intermediaries "should not be peeking inside the body at all" is
                        > another.

                        You lost me there. I thought you were talking about not looking
                        inside the body for performance reasons. HTTP is designed so that
                        an intermediary doesn't have to look inside the body (for performance
                        reasons), but that is not a constraint of REST and thus it is common
                        to have intermediaries that do want to look inside the body.

                        > I questioned the assertion because it is not uncommon to see
                        > gateway proxies mucking about in bodies, rewriting URIs etc.And while
                        > this is often criticized for all the obvious reasons, I wasn't aware
                        > of any well-defined rule that was being violated. SIP contains
                        > language like "The proxy MUST NOT add to, modify, or remove the
                        > message body." so that sort of proxy behavior would be a violation of
                        > the protocol. I assumed that HTTP didn't contain this sort of language
                        > because it was overly restrictive (e.g. if you must resort to
                        > something like URI rewriting then you can as long as you are prepared
                        > to deal with the costs). Is this not the case?

                        HTTP does not contain such a restriction because transducing proxies
                        and mash-up gateways are considered features. That is part of the
                        REST style.

                        > Also, I'm curious as to why this couldn't be a style issue. The
                        > closest thing I've found to architectural style-like constraints for
                        > the SIP architecture is Rosenberg's Architecture and Design Principles
                        > for SIP (http://tools.ietf.org/html/draft-rosenberg-sipping-sip-arch-01
                        > ).
                        > It describes the "Proxies are for routing" principle which assigns a
                        > specific role to intermediaries -- similar to the roles assigned by
                        > the client-server constraint. One might argue that the SIP protocol
                        > constraint quoted above is derived from this principle. Is there some
                        > reason that an architectural style couldn't or shouldn't contain a
                        > constraint that implies that intermediaries never modify message
                        > bodies?

                        No, that is a common constraint. Not in REST, but certainly in
                        other styles of interaction and in much of the design around the
                        core Internet protocols (the end-to-end principle). However, it
                        isn't quite right to call them intermediaries, at least if you are
                        following my definitions of software architecture. Those are
                        called connectors.

                        An intermediary is a component that is allowed to do intermediation,
                        which in my opinion implies the ability to change the payload.

                        Sorry for the confusion.

                        ....Roy
                      • Mike Kelly
                        ... I think there is an additional benefit, beyond performance gains, derived from requiring a system s intermediary/connector controls to be represented as
                        Message 11 of 12 , Nov 3, 2009
                          Roy T. Fielding wrote:
                          > On Nov 2, 2009, at 10:07 PM, Andrew Wahbe wrote:
                          >
                          >> Fair enough, but the fact that self-descriptive messages enable
                          >> efficient processing by intermediaries is one thing; and asserting
                          >> that intermediaries "should not be peeking inside the body at all" is
                          >> another.
                          >>
                          >
                          > You lost me there. I thought you were talking about not looking
                          > inside the body for performance reasons. HTTP is designed so that
                          > an intermediary doesn't have to look inside the body (for performance
                          > reasons), but that is not a constraint of REST and thus it is common
                          > to have intermediaries that do want to look inside the body.
                          >
                          >

                          I think there is an additional benefit, beyond performance gains,
                          derived from requiring a system's intermediary/connector controls to be
                          represented as protocol-level metadata (i.e. HTTP headers) - since this
                          removes a system specific burden (of self-descriptiveness) on media
                          types, and therefore promotes flexibility in terms of how resources can
                          be represented over time.

                          Such as system would not necessarily prevent duplication of this
                          information within specific media types, if required - although there
                          would be some cost associated with ensuring this enveloped information
                          within the body is consistent with the 'authoritative' information in
                          the accompanying headers.


                          - Mike
                        • William Martinez Pomares
                          Hello Jan. Sorry to mix this in. In WSA world, particularly the SOAP definition, you have headers. The idea is that you may want to have intermediaries or
                          Message 12 of 12 , Nov 8, 2009
                            Hello Jan.
                            Sorry to mix this in.
                            In WSA world, particularly the SOAP definition, you have headers.
                            The idea is that you may want to have intermediaries or connectors (using Roy's definitions) between the origin and the destination. If you want to encrypt the payload, fine. Headers are still enough info to manage all in-the-middle needs.

                            But then, does it make the message non self-descriptive? What is the meaning of that? I think it is not the idea of a message anyone can read and know exactly what is happening. Let's see: to me, it makes no sense to think someone, that does not know anything about you app, nor anything about your business, may take any message in time, and completely know all the app history, what is the app state, what is it going on, and how will it end.

                            SO, we can assume people that finds a message, may know what it is if it knows a little about the business. It may actually know what's up with the app if it knows the app. But if the one that finds the message is one of the intended intermediaries, it should know what is going on, and should know how to act at the event. In SOAP world there are elements to indicate intermediaries if they should process, pass or need to understand about the message, without knowing the payload. And it makes sense (a little).

                            So, in your example, the actual fact that William does not know what is happening in the message with a form encoded data does not break any REST rule, if William is not part of your app. And if William is, it may actually need to know something in the HTTP headers to process, without even looking at payload. And if William needs to process the payload, it will be actually expecting that format, don't you think?

                            The problem we often find in REST, is that it was designed for networked systems, with large grained hypermedia transfer apps. That is a domain, a clearly defined one, with media types created for it. Sometimes, you need a new media type, and if you dare to use your own, some people may jump and say that is out-of-band information, forcing you to use types not suitable for you app. Or maybe, your app is not suitable for REST. It may be out-of-band in that domain, but not in yours. Probably that is a discussion someday, someone may start: Do you want to follow REST or the Web Implementation? Interesting.

                            Cheers!

                            William Martinez.

                            --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                            >
                            > On thing that keeps bugging me....
                            >
                            > Suppose I have an order accepting resource /order-processor-a and the
                            > client has discovered that it accepts application/order+xml (assuming
                            > the type being a standard type). Order submissions would be done with
                            >
                            > (Case A:)
                            >
                            > POST /order-processor-a
                            > Content-Type: application/order+xml
                            >
                            > <order>
                            > <item>A</item>
                            > <item>B</item>
                            > </order>
                            >
                            > Now suppose I had another order processor that accepts submission of
                            > orders in the form of form data, e.g.
                            >
                            >
                            > (Case B:)
                            >
                            > POST /order-processor-b
                            > Content-Type: application/x-www-form-urlencoded
                            >
                            > item=A&item=B
                            >
                            >
                            > Isn't case B violating REST's message self descriptiveness constraint
                            > because the meaning of the message depends on the knowledge that the
                            > recipient is an order processor? IOW, an observer could only figure
                            > out the meaning if it knew the past interactions and not form the
                            > message itself.
                            >
                            > Is application/x-www-form-urlencoded as bad a choice as application/
                            > xml? In fact, is any general media type (e.g. text/uri-list) a
                            > violation of the message self descriptiveness constraint?
                            >
                            > Thanks,
                            >
                            > Jan
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.