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

Re: [rest-discuss] Appropriate status code when creating a lock fails?

Expand Messages
  • Subbu Allamaraju
    Just curious - why would the server want to lock a resource? Subbu
    Message 1 of 10 , Jul 4, 2009
    • 0 Attachment
      Just curious - why would the server want to lock a resource?

      Subbu

      On Jul 3, 2009, at 7:01 PM, Jan Algermissen wrote:

      >
      >
      > Hi,
      >
      > suppose a situation where clients know that creating a lock on some
      > resource
      >
      > http://www.example.com/docs/1234
      >
      > is done by PUTing to
      >
      > http://www.example.com/properties/1234?lock
      >
      > I see two ways how to address the situation that the lock can alreay
      > exist and that the
      > request should then fail:
      >
      > a) PUT /properties/1234?lock
      > If-None-Match: *
      >
      > 304 Precondition Failed
      >
      > b) PUT /properties/1234?lock
      >
      > 409 Conflict
      >
      > The former bears the question what the server should do when the
      > client does not make
      > the request condtional (-> 409??) and regading the latter I am not
      > sure if the semantics
      > are correct.
      >
      > Can anybody provide a clue?
      >
      > Jan
      >
      >
      >
    • Subbu Allamaraju
      Just curious - why would the server want to offer such a functionality as locking to its clients? Subbu
      Message 2 of 10 , Jul 4, 2009
      • 0 Attachment
        Just curious - why would the server want to offer such a functionality
        as locking to its clients?

        Subbu

        On Jul 3, 2009, at 7:01 PM, Jan Algermissen wrote:

        >
        >
        > Hi,
        >
        > suppose a situation where clients know that creating a lock on some
        > resource
        >
        > http://www.example.com/docs/1234
        >
        > is done by PUTing to
        >
        > http://www.example.com/properties/1234?lock
        >
        > I see two ways how to address the situation that the lock can alreay
        > exist and that the
        > request should then fail:
        >
        > a) PUT /properties/1234?lock
        > If-None-Match: *
        >
        > 304 Precondition Failed
        >
        > b) PUT /properties/1234?lock
        >
        > 409 Conflict
        >
        > The former bears the question what the server should do when the
        > client does not make
        > the request condtional (-> 409??) and regading the latter I am not
        > sure if the semantics
        > are correct.
        >
        > Can anybody provide a clue?
        >
        > Jan
        >
        >
        >
      • Jan Algermissen
        ... Because it is (currently) a requirement of the owners of the system to use a pessimistic locking strategy, IOW, not HTTPs conditional write approach with
        Message 3 of 10 , Jul 4, 2009
        • 0 Attachment
          On Jul 4, 2009, at 7:04 PM, Subbu Allamaraju wrote:

          > Just curious - why would the server want to offer such a functionality
          > as locking to its clients?

          Because it is (currently) a requirement of the owners of the system to
          use a pessimistic locking strategy, IOW, not HTTPs conditional write
          approach with If-Match.

          Jan



          >
          > Subbu
          >
          > On Jul 3, 2009, at 7:01 PM, Jan Algermissen wrote:
          >
          >>
          >>
          >> Hi,
          >>
          >> suppose a situation where clients know that creating a lock on some
          >> resource
          >>
          >> http://www.example.com/docs/1234
          >>
          >> is done by PUTing to
          >>
          >> http://www.example.com/properties/1234?lock
          >>
          >> I see two ways how to address the situation that the lock can alreay
          >> exist and that the
          >> request should then fail:
          >>
          >> a) PUT /properties/1234?lock
          >> If-None-Match: *
          >>
          >> 304 Precondition Failed
          >>
          >> b) PUT /properties/1234?lock
          >>
          >> 409 Conflict
          >>
          >> The former bears the question what the server should do when the
          >> client does not make
          >> the request condtional (-> 409??) and regading the latter I am not
          >> sure if the semantics
          >> are correct.
          >>
          >> Can anybody provide a clue?
          >>
          >> Jan
          >>
          >>
          >>
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Subbu Allamaraju
          Leaving aside the question of whether pessimistic locking over the web is a good or bad, I would expect a lock at the end of this operation. This of course,
          Message 4 of 10 , Jul 4, 2009
          • 0 Attachment
            Leaving aside the question of whether pessimistic locking over the web
            is a good or bad, I would expect a lock at the end of this operation.
            This of course, leads to the pattern that the author(s) of RETRO tried.

            Subbu

            On Jul 4, 2009, at 4:08 PM, Jan Algermissen wrote:

            >
            > On Jul 4, 2009, at 7:04 PM, Subbu Allamaraju wrote:
            >
            >> Just curious - why would the server want to offer such a
            >> functionality
            >> as locking to its clients?
            >
            > Because it is (currently) a requirement of the owners of the system
            > to use a pessimistic locking strategy, IOW, not HTTPs conditional
            > write approach with If-Match.
            >
            > Jan
            >
            >
            >
            >>
            >> Subbu
            >>
            >> On Jul 3, 2009, at 7:01 PM, Jan Algermissen wrote:
            >>
            >>>
            >>>
            >>> Hi,
            >>>
            >>> suppose a situation where clients know that creating a lock on some
            >>> resource
            >>>
            >>> http://www.example.com/docs/1234
            >>>
            >>> is done by PUTing to
            >>>
            >>> http://www.example.com/properties/1234?lock
            >>>
            >>> I see two ways how to address the situation that the lock can alreay
            >>> exist and that the
            >>> request should then fail:
            >>>
            >>> a) PUT /properties/1234?lock
            >>> If-None-Match: *
            >>>
            >>> 304 Precondition Failed
            >>>
            >>> b) PUT /properties/1234?lock
            >>>
            >>> 409 Conflict
            >>>
            >>> The former bears the question what the server should do when the
            >>> client does not make
            >>> the request condtional (-> 409??) and regading the latter I am not
            >>> sure if the semantics
            >>> are correct.
            >>>
            >>> Can anybody provide a clue?
            >>>
            >>> Jan
            >>>
            >>>
            >>>
            >>
            >>
            >>
            >> ------------------------------------
            >>
            >> Yahoo! Groups Links
            >>
            >>
            >>
            >
          • Bill de hOra
            ... Use WebDAV LOCK http://msdn.microsoft.com/en-us/library/aa142897%28EXCHG.65%29.aspx Bill
            Message 5 of 10 , Jul 5, 2009
            • 0 Attachment
              Jan Algermissen wrote:
              >
              >
              >
              >
              > On Jul 4, 2009, at 7:04 PM, Subbu Allamaraju wrote:
              >
              > > Just curious - why would the server want to offer such a functionality
              > > as locking to its clients?
              >
              > Because it is (currently) a requirement of the owners of the system to
              > use a pessimistic locking strategy, IOW, not HTTPs conditional write
              > approach with If-Match.

              Use WebDAV LOCK

              http://msdn.microsoft.com/en-us/library/aa142897%28EXCHG.65%29.aspx

              Bill
            • Sam Johnston
              ... For my current application (cloud infrastructure API) there are a number of places where such locking would be useful - for example when dealing with
              Message 6 of 10 , Jul 6, 2009
              • 0 Attachment
                On Sun, Jul 5, 2009 at 1:04 AM, Subbu Allamaraju <subbu@...> wrote:
                Just curious - why would the server want to offer such a functionality
                as locking to its clients?

                For my current application (cloud infrastructure API) there are a number of places where such locking would be useful - for example when dealing with virtual machine disk images, and it's not hard to conceive of other similar applications like event ticketing.

                In any case my preference is to facilitate users and see what is used (e.g. draft-johnston-http-category-header) than to try to dictate to them what they can and can't do... what the BBC said today about content ("We need to stop acting like custodians, and more like facilitators") arguably applies to the standards community too... else they'll just make stuff up.

                Sam

                On Jul 3, 2009, at 7:01 PM, Jan Algermissen wrote:

                >
                >
                > Hi,
                >
                > suppose a situation where clients know that creating a lock on some
                > resource
                >
                > http://www.example.com/docs/1234
                >
                > is done by PUTing to
                >
                > http://www.example.com/properties/1234?lock
                >
                > I see two ways how to address the situation that the lock can alreay
                > exist and that the
                > request should then fail:
                >
                > a) PUT /properties/1234?lock
                > If-None-Match: *
                >
                > 304 Precondition Failed
                >
                > b) PUT /properties/1234?lock
                >
                > 409 Conflict
                >
                > The former bears the question what the server should do when the
                > client does not make
                > the request condtional (-> 409??) and regading the latter I am not
                > sure if the semantics
                > are correct.
                >
                > Can anybody provide a clue?
                >
                > Jan
                >
                >
                >



                ------------------------------------

                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                   http://groups.yahoo.com/group/rest-discuss/

                <*> Your email settings:
                   Individual Email | Traditional

                <*> To change settings online go to:
                   http://groups.yahoo.com/group/rest-discuss/join
                   (Yahoo! ID required)

                <*> To change settings via email:
                   mailto:rest-discuss-digest@yahoogroups.com
                   mailto:rest-discuss-fullfeatured@yahoogroups.com

                <*> To unsubscribe from this group, send an email to:
                   rest-discuss-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                   http://docs.yahoo.com/info/terms/


              • Julian Reschke
                ... Or . BR, Julian
                Message 7 of 10 , Jul 6, 2009
                • 0 Attachment
                  Bill de hOra wrote:
                  >
                  >
                  >
                  > Jan Algermissen wrote:
                  > >
                  > >
                  > >
                  > >
                  > > On Jul 4, 2009, at 7:04 PM, Subbu Allamaraju wrote:
                  > >
                  > > > Just curious - why would the server want to offer such a functionality
                  > > > as locking to its clients?
                  > >
                  > > Because it is (currently) a requirement of the owners of the system to
                  > > use a pessimistic locking strategy, IOW, not HTTPs conditional write
                  > > approach with If-Match.
                  >
                  > Use WebDAV LOCK
                  >
                  > http://msdn. microsoft. com/en-us/ library/aa142897 %28EXCHG. 65%29.aspx
                  > <http://msdn.microsoft.com/en-us/library/aa142897%28EXCHG.65%29.aspx>

                  Or <http://greenbytes.de/tech/webdav/rfc4918.html#METHOD_LOCK>.

                  BR, Julian
                Your message has been successfully submitted and would be delivered to recipients shortly.