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

Re: [rest-discuss] Re: Introductory REST Article

Expand Messages
  • 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 1 of 25 , Jan 2, 2008
    View Source
    • 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 2 of 25 , Jan 2, 2008
      View Source
      • 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 3 of 25 , Jan 2, 2008
        View Source
        • 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 4 of 25 , Jan 2, 2008
          View Source
          • 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 5 of 25 , Jan 2, 2008
            View Source
            • 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 6 of 25 , Jan 2, 2008
              View Source
              • 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 7 of 25 , Jan 2, 2008
                View Source
                • 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 8 of 25 , Jan 2, 2008
                  View Source
                  • 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.