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

Re: Introductory REST Article

Expand Messages
  • Ebenezer Ikonne
    ... Good article howver the business operation submitOrder was not taken care of. For anyone seriously thinking of adopting REST and making a mindshift
    Message 1 of 25 , Dec 31, 2007
    • 0 Attachment
      --- In rest-discuss@yahoogroups.com, Stefan Tilkov <stefan.tilkov@...>
      wrote:
      >
      > I've written an introductory article about REST for InfoQ:
      >
      > http://www.infoq.com/articles/rest-introduction
      >
      > Feedback is most welcome.
      >
      > BTW: InfoQ is still looking for article contributions regarding REST,
      > Web-style, RESTful Web services (or whatever your favorite moniker for
      > "using the Web as it's supposed to be used" is).
      >
      > Thanks,
      > Stefan
      >

      Good article howver the business operation "submitOrder" was not taken
      care of. For anyone seriously thinking of adopting REST and making a
      mindshift change, they'd probably appreciate seeing you show the
      resource and method used to handle this
    • Stefan Tilkov
      ... Thanks - the resource diagram says add a new order when it should really be submit order . I ll clarify this in an update (I use this diagram a lot).
      Message 2 of 25 , Jan 2, 2008
      • 0 Attachment
        On Jan 1, 2008, at 6:44 AM, Ebenezer Ikonne wrote:

        >
        >
        > --- In rest-discuss@yahoogroups.com, Stefan Tilkov <stefan.tilkov@...>
        > wrote:
        > >
        > > I've written an introductory article about REST for InfoQ:
        > >
        > > http://www.infoq.com/articles/rest-introduction
        > >
        > > Feedback is most welcome.
        > >
        > > BTW: InfoQ is still looking for article contributions regarding
        > REST,
        > > Web-style, RESTful Web services (or whatever your favorite moniker
        > for
        > > "using the Web as it's supposed to be used" is).
        > >
        > > Thanks,
        > > Stefan
        > >
        >
        > Good article howver the business operation "submitOrder" was not taken
        > care of. For anyone seriously thinking of adopting REST and making a
        > mindshift change, they'd probably appreciate seeing you show the
        > resource and method used to handle this
        >
        >

        Thanks - the resource diagram says "add a new order" when it should
        really be "submit order". I'll clarify this in an update (I use this
        diagram a lot).

        Stefan
        --
        Stefan Tilkov, http://www.innoq.com/blog/st/
      • Ebenezer Ikonne
        ... taken ... Ah, so submit order is pretty much the creation of an order. I actually thought submit order had a different meaning which is why I made my
        Message 3 of 25 , Jan 2, 2008
        • 0 Attachment
          --- In rest-discuss@yahoogroups.com, Stefan Tilkov <stefan.tilkov@...>
          wrote:
          >
          > On Jan 1, 2008, at 6:44 AM, Ebenezer Ikonne wrote:
          >
          > >
          > >
          > > --- In rest-discuss@yahoogroups.com, Stefan Tilkov stefan.tilkov@
          > > wrote:
          > > >
          > > > I've written an introductory article about REST for InfoQ:
          > > >
          > > > http://www.infoq.com/articles/rest-introduction
          > > >
          > > > Feedback is most welcome.
          > > >
          > > > BTW: InfoQ is still looking for article contributions regarding
          > > REST,
          > > > Web-style, RESTful Web services (or whatever your favorite moniker
          > > for
          > > > "using the Web as it's supposed to be used" is).
          > > >
          > > > Thanks,
          > > > Stefan
          > > >
          > >
          > > Good article howver the business operation "submitOrder" was not
          taken
          > > care of. For anyone seriously thinking of adopting REST and making a
          > > mindshift change, they'd probably appreciate seeing you show the
          > > resource and method used to handle this
          > >
          > >
          >
          > Thanks - the resource diagram says "add a new order" when it should
          > really be "submit order". I'll clarify this in an update (I use this
          > diagram a lot).
          >
          > Stefan
          > --
          > Stefan Tilkov, http://www.innoq.com/blog/st/
          >

          Ah, so 'submit order' is pretty much the creation of an order. I
          actually thought 'submit order" had a different meaning which is why I
          made my comment. The content is very good for an introductory article.
          I hope to see a more intermediate article soon.
        • Bob Haugen
          ... I had the same question. My usual interpretation is that creating an order is different from submitting an order. An order is an offer to buy. It usually
          Message 4 of 25 , Jan 2, 2008
          • 0 Attachment
            On Jan 2, 2008 9:02 AM, Ebenezer Ikonne <amaeze@...> wrote:
            > Ah, so 'submit order' is pretty much the creation of an order. I
            > actually thought 'submit order" had a different meaning which is why I
            > made my comment.

            I had the same question. My usual interpretation is that creating an
            order is different from submitting an order.

            An order is an offer to buy. It usually goes through a business
            protocol called Offer-Acceptance (Google for it).

            Submit order usually means submit the offer to the seller to see if it
            is accepted or not.

            So for example you might create an order and save it as a resource
            without submitting it for acceptance. Maybe even change it before
            submitting it, since changing it after acceptance means another
            offer-acceptance protocol for the changes.

            But Stefan's case appears to be a design for the seller's internal
            system, where creating an order may mean it already has been submitted
            by the customer and accepted by the seller.

            Or maybe I'm wrong...
          • Ebenezer Ikonne
            Even in an internal system, submit could mean something else. It could indicate the need to process or fulfill the order. These are the type of operations
            Message 5 of 25 , Jan 2, 2008
            • 0 Attachment
              Even in an internal system, "submit" could mean something else. It
              could indicate the need to process or fulfill the order. These are the
              type of operations most people that I know are interested in REST want
              to see demonstrated.
            • Stefan Tilkov
              I ve chosen to map submit order to a POST to the collection resource identified by /orders. The POST would return the URI of a new resource (the order) in a
              Message 6 of 25 , Jan 2, 2008
              • 0 Attachment
                I've chosen to map "submit order" to a POST to the collection resource
                identified by /orders. The POST would return the URI of a new resource
                (the order) in a Location header.
                For a generic client, everything should be fine since this is just
                standard behavior. (Another option would have been to use PUT, with
                the downside of the client having to choose the URI, and the benefit
                of being idempotent.)

                For a client that's aware of the business semantics, it means
                submitting an order. Of course this would have to be communicated by
                means of documentation, possibly via some click-through agreement.

                Stefan
                --
                Stefan Tilkov, http://www.innoq.com/blog/st/


                On Jan 2, 2008, at 6:05 PM, Ebenezer Ikonne wrote:

                > Even in an internal system, "submit" could mean something else. It
                > could indicate the need to process or fulfill the order. These are the
                > type of operations most people that I know are interested in REST want
                > to see demonstrated.
                >
                >
                >
              • Ebenezer Ikonne
                This works as in your sample submit means create . If submit was a distinct operation from create, you would have to do something different. Any thoughts
                Message 7 of 25 , Jan 2, 2008
                • 0 Attachment
                  This works as in your sample "submit" means "create". If submit was
                  a distinct operation from create, you would have to do something
                  different. Any thoughts on that?
                  --- In rest-discuss@yahoogroups.com, Stefan Tilkov
                  <stefan.tilkov@...> wrote:
                  >
                  > I've chosen to map "submit order" to a POST to the collection
                  resource
                  > identified by /orders. The POST would return the URI of a new
                  resource
                  > (the order) in a Location header.
                  > For a generic client, everything should be fine since this is just
                  > standard behavior. (Another option would have been to use PUT,
                  with
                  > the downside of the client having to choose the URI, and the
                  benefit
                  > of being idempotent.)
                  >
                  > For a client that's aware of the business semantics, it means
                  > submitting an order. Of course this would have to be communicated
                  by
                  > means of documentation, possibly via some click-through agreement.
                  >
                  > Stefan
                  > --
                  > Stefan Tilkov, http://www.innoq.com/blog/st/
                  >
                  >
                  > On Jan 2, 2008, at 6:05 PM, Ebenezer Ikonne wrote:
                  >
                  > > Even in an internal system, "submit" could mean something else. It
                  > > could indicate the need to process or fulfill the order. These
                  are the
                  > > type of operations most people that I know are interested in REST
                  want
                  > > to see demonstrated.
                  > >
                  > >
                  > >
                  >
                • Stefan Tilkov
                  ... Anything can be mapped to GET, PUT, POST, or DELETE -- you just have to decide which of these is the best match. For example, you could do an order state
                  Message 8 of 25 , Jan 2, 2008
                  • 0 Attachment
                    On Jan 2, 2008, at 9:56 PM, Ebenezer Ikonne wrote:
                    > This works as in your sample "submit" means "create". If submit was
                    > a distinct operation from create, you would have to do something
                    > different. Any thoughts on that?
                    >

                    Anything can be mapped to GET, PUT, POST, or DELETE -- you just have
                    to decide which of these is the best match. For example, you could do
                    an order state change - let's say it goes from "submitted" to
                    "shipped" - by either doing a PUT to update the state, or a POST to
                    create a sub-resource (which has the benefit of creating an audit
                    trail).

                    So e.g. I could do

                    POST /orders/4711/states
                    <shipped>...</shipped>

                    and get back a Location of a state notification; the order itself
                    would reflect the change as well (nothing prevents you from changing
                    resources other than the one specified in the URI). Alternatively, I
                    could move the resource from one collection to another (discussed a
                    while back here).

                    Stefan
                    --
                    Stefan Tilkov, http://www.innoq.com/blog/st/
                  • Ebenezer Ikonne
                    I generally agree with what you ve suggested and I believe we had this discussion a while. I like using POST to a collection (or state) whenever its more than
                    Message 9 of 25 , Jan 2, 2008
                    • 0 Attachment
                      I generally agree with what you've suggested and I believe we had this
                      discussion a while. I like using POST to a collection (or state)
                      whenever its more than a partial update - just my preference.

                      > So e.g. I could do
                      >
                      > POST /orders/4711/states
                      > <shipped>...</shipped>

                      What are you returned when a GET is done on the resource above?
                    Your message has been successfully submitted and would be delivered to recipients shortly.