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

Re: [rest-discuss] Re: RESTify a business document exchange app

Expand Messages
  • S. Mike Dierken
    ... From: bhaugen32 ... to ... audit ... I ... The status messages are just advisory and notify the sender of the biz docs process
    Message 1 of 15 , Mar 5, 2002
    • 0 Attachment
      ----- Original Message -----
      From: "bhaugen32" <bhaugen32@...>

      >
      > > In the sample the status is updated with PUT - but if the server wants
      to
      > > keep a history, perhaps it should be POST. But I don't want the clients
      > > needing to know what the server intends to do. I'd like to expose the
      > > resource as the 'current status' - no assumptions about 'extending' an
      audit
      > > trail - and so I used PUT. If the server chooses to keep history, then
      I
      > > suppose a new resource is needed for the audit trail - which would be a
      > > collection of previously PUT entities.
      >
      > The above paragraph seems to imply that you are thinking of something
      > different for status than simple ACKs.
      The status messages are just advisory and notify the sender of the biz docs
      process through the receivers business process.
      If the receiver's business process spawns multiple biz docs, then the status
      notifications shouldn't be used - since they are only 'advisory'. The new
      business docs should be sent to the sender - probably as a POST to the
      Reply-To location. I'm using POST here to 'extend' the originating document
      with related material. The Reply-To in the example says '.../ack' so maybe
      something isn't quite right.

      >
      > Are you thinking of Delivery and Payment as statuses? If so, I got
      > an argument for you...
      >
      Um, not sure what a 'status' is - but my notification would be advisory and
      real biz docs would deserve real URI based exchange.
    • Mark Baker
      ... Except that then you lose the Accepted bit, which is really the most important one. I noticed that 201 didn t include the Location header some time ago,
      Message 2 of 15 , Mar 6, 2002
      • 0 Attachment
        > > The existence of a document might imply business acceptance - which is not
        > > correct. If the business process defines acknowledgement or status documents
        > > that have 'accepted', 'rejected' and 'undecided' values, then this would be
        > > fine I think (retrieving the status document tells you if it was actually
        > > approved). If the business document set doesn't define 'undecided' values
        > > then the Location header might need to reference a resource that does not
        > > yet exist - and when it does exist the values within would specify
        > > 'accepted' or 'rejected'.
        >
        > Wouldn't it be legitimate to return "Created" with a Location header in this
        > case. After all, you did create a resource--the status document you describe
        > above.

        Except that then you lose the "Accepted" bit, which is really the most
        important one.

        I noticed that 201 didn't include the Location header some time ago, but
        forgot to bring it up. I think it would be a great idea to include it,
        as it would permit simpler automation of asynchronous processing with
        HTTP. Anybody want to raise this with on the HTTP WG mailing list?
        It might be added to the errata - I consider it an oversight, and I
        doubt there's any deployment issue with doing it.

        Another option would be the use the DAV "multistatus" feature where
        a response includes a XML body that includes multiple response codes.
        This way it could return both 201 and 202.

        MB
        --
        Mark Baker, Chief Science Officer, Planetfred, Inc.
        Ottawa, Ontario, CANADA. mbaker@...
        http://www.markbaker.ca http://www.planetfred.com
      • bhaugen32
        ... Is that a counter-proposal to Mike Dierken s proposal of a Response location where the Accepted bits would be part of the response? If so, how would you
        Message 3 of 15 , Mar 6, 2002
        • 0 Attachment
          Mark Baker <distobj@a...> wrote:
          > s/Accept/Accepted

          Is that a counter-proposal to Mike Dierken's proposal of a Response
          location where the "Accepted" bits would be part of the response?

          If so, how would you handle the very common case where there are
          three possible responses: Accepted, Rejected, or CounterPending. The
          third meaning that we're still negotiating the deal.

          (I'm not arguing for or against any proposal here, just trying to
          understand.)

          -Bob Haugen
        • Mark Baker
          ... No no, just that in HTTP, Accepted is the 202 response, and Accept is the request header used to request content negotiation by media type. ... If I ve
          Message 4 of 15 , Mar 6, 2002
          • 0 Attachment
            > Mark Baker <distobj@a...> wrote:
            > > s/Accept/Accepted
            >
            > Is that a counter-proposal to Mike Dierken's proposal of a Response
            > location where the "Accepted" bits would be part of the response?

            No no, just that in HTTP, "Accepted" is the 202 response, and "Accept"
            is the request header used to request content negotiation by media type.

            > If so, how would you handle the very common case where there are
            > three possible responses: Accepted, Rejected, or CounterPending. The
            > third meaning that we're still negotiating the deal.

            If I've followed the discussion so far, all of those are states of a
            resource, and so should be carried over 2xx responses. Just as HTTP's
            methods apply to all resources, so does its response codes - they
            have to remain generic.

            MB
            --
            Mark Baker, Chief Science Officer, Planetfred, Inc.
            Ottawa, Ontario, CANADA. mbaker@...
            http://www.markbaker.ca http://www.planetfred.com
          Your message has been successfully submitted and would be delivered to recipients shortly.