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

Re: [rest-discuss] Updating metadata of multiple resources

Expand Messages
  • Stefano Masini
    First of all thank you all for the great responses this thread got. They were very helpful to a starter like me. So thank you. But now let me get this
    Message 1 of 19 , May 4, 2008
    • 0 Attachment
      First of all thank you all for the great responses this thread got.
      They were very helpful to a starter like me. So thank you.

      But now let me get this straight. I hope you'll forgive my naive questions.

      On Sun, May 4, 2008 at 2:39 AM, Sebastien Lambla <seb@...> wrote:
      > > than HTML forms are; it's just another media type. It's not "specific
      > > to my service" because, once again, it's a (hypothetical) standard
      > > media type.
      >
      > You may well be right in the sense that you rely on an informational
      > resource to tell you how to construct a url. That said, I fail to see how
      > [...]

      I'll hook up here, and try to go back to my original example.

      So I think I understand (and like) the principle of discoverability,
      in the sense that the client should not be held responsible to come up
      with urls. Instead it should somehow be told about them by the server.
      The client remains responsible for is the _why_ a given url is needed,
      but the _how_ is told by the server. Good.

      So, back to my image repository example: let's assume that the
      preferred representation is Json and that the client wants to make use
      of a url identifying a given set of images. Gary proposed an approach
      making use of a "text/html-with-javascript-links" media type, with the
      representation being some html containing a javascript code snippet.
      My first question: can I safely translate that proposal to my example
      by rewriting that code snippet as the following Json data structure?
      {
      imageSetUrlBuilder: "function(ids) { return '/resources/' + ids.join(','); }"
      }

      The client application, of course, should know how to deal with such
      information, just like it should know about the
      text/html-with-javascript-links media type, or anything else. I'd say,
      it actually _expects_ it, rather than just knowing how to deal with
      it.

      Now my second question: which part of my url space is better suited
      for containing this piece of Json?
      If I think about it, it seems like some sort of application global
      "information". It's a piece of functionality (in the form of a
      javascript code snippet) that the client app needs to fetch right at
      the beginning in order to be fully functional. So, I'd say, the root
      url (/) is the best place, together with all the other stuff I might
      like to include in the root url, i.e. the one representing my
      application in general, including other urls. For example:
      {
      imageSetUrlBuilder: "function(ids) { return '/resources/' + ids.join(','); }",
      allImagesUrl: "/images",
      title: "My fancy application"
      }

      What do you think? Am I beginning to see more RESTy? :)

      Thanks
      Stefano
    • Subbu Allamaraju
      ... I don t disagree. But today s infrastructure does not deal with POST, PUT etc packaged inside multipart messages. For instance, a cache can t mark an entry
      Message 2 of 19 , May 4, 2008
      • 0 Attachment
        On May 4, 2008, at 8:39 AM, Sebastien Lambla wrote:
        >> While this approach looks better than pipelining, it is more like
        >> SOAP
        >> than HTTP. What is the difference between this, and say, packaging
        >> the
        >> same parts as some XML elements inside some envelope element?
        >
        > Several benefits:
        > - Multipart messages are a standard way to represent compound payloads
        > - You don't enforce the use of xml

        I don't disagree. But today's infrastructure does not deal with POST,
        PUT etc packaged inside multipart messages. For instance, a cache
        can't mark an entry in the cache stale when a PUT is submitted via a
        multipart message. Yes, there are theoretical benefits, but it is
        difficult to realize those benefits in reality.

        The basic motivation for proposals like this is to let a client submit
        a bunch of requests and get them executed in at once. The supposed
        benefit for the client is that it does not have to make "n" number of
        requests. However, IMO, once we get into the details, the picture
        won't be as simple as this. For instance, what is the cost for the
        client to recover from partial failures? What is cost for the client
        and server to use two different code paths - one for regular requests
        and another for batch requests? Does the client sufficiently
        understand the difference between non-idempotent requests and
        idempotent requests bundled in the same batch? For the simple cases,
        yes, the answers may be simple, but IMO, the complexity of batch may
        outweigh the benefits.

        Moreover, in most cases, even if pipelining could not be replied upon
        for whatever reasons, by modeling resources cleverly, it may be
        possible to avoid the need for batch.

        Sincerely,
        Subbu
      • Bill de hOra
        ... For AtomPub servers, I implement this for batch tagging: POST /categorise host: example.org ...
        Message 3 of 19 , May 6, 2008
        • 0 Attachment
          Stefano Masini wrote:
          >
          >
          > Hi,
          >
          > I'm still trying to figure rest out. Let's see if I hit a sweet spot
          > or if I'm just missing something (more likely, please forgive me).
          >
          > I have several images, each with its own uri that have metadata.
          > If I want to update the metadata of a given image I send a POST
          > request on its uri. Right?
          > What if I want to atomically update some metadata (say, a tag) for a
          > group of images, how do I approach that?
          > Sending multiple POST requests, one for each uri, is not atomic, so I
          > can't accept it.

          For AtomPub servers, I implement this for batch tagging:

          POST /categorise
          host: example.org

          <categories ...>
          <category term="foo" >
          <atom:id>...</atom:id>
          <atom:id>...</atom:id>
          <atom:id>...</atom:id>
          </category>
          <category term="foo" >
          <atom:id>...</atom:id>
          <atom:id>...</atom:id>
          <atom:id>...</atom:id>
          </category>
          </categories>

          and have a symmetric uncategorise service for removing tags. I'm still
          working on batch title edits, which is the other common usecase I run into.

          Bill
        • Steve Loughran
          ... 1. There is some bulk operation in WebDAV, which then requires the notion of partial failure to come back in the response; a simple single error code is no
          Message 4 of 19 , May 7, 2008
          • 0 Attachment
            On Mon, May 5, 2008 at 12:44 AM, Subbu Allamaraju <subbu@...> wrote:
            >
            > On May 4, 2008, at 8:39 AM, Sebastien Lambla wrote:
            > >> While this approach looks better than pipelining, it is more like
            > >> SOAP
            > >> than HTTP. What is the difference between this, and say, packaging
            > >> the
            > >> same parts as some XML elements inside some envelope element?
            > >
            > > Several benefits:
            > > - Multipart messages are a standard way to represent compound payloads
            > > - You don't enforce the use of xml
            >
            > I don't disagree. But today's infrastructure does not deal with POST,
            > PUT etc packaged inside multipart messages. For instance, a cache
            > can't mark an entry in the cache stale when a PUT is submitted via a
            > multipart message. Yes, there are theoretical benefits, but it is
            > difficult to realize those benefits in reality.
            >
            > The basic motivation for proposals like this is to let a client submit
            > a bunch of requests and get them executed in at once. The supposed
            > benefit for the client is that it does not have to make "n" number of
            > requests. However, IMO, once we get into the details, the picture
            > won't be as simple as this. For instance, what is the cost for the
            > client to recover from partial failures? What is cost for the client
            > and server to use two different code paths - one for regular requests
            > and another for batch requests? Does the client sufficiently
            > understand the difference between non-idempotent requests and
            > idempotent requests bundled in the same batch? For the simple cases,
            > yes, the answers may be simple, but IMO, the complexity of batch may
            > outweigh the benefits.

            1. There is some bulk operation in WebDAV, which then requires the
            notion of partial failure to come back in the response; a simple
            single error code is no longer enough

            2. WS-ResourceFramework, while near the pinnacle of WS-*, tried to
            retrofit bulk operations to its resource-model-atop-SOAP world view,
            and again, got into a mess about atomicity of updates as well as
            failures. What I dont like about it (apart from it being the pinnacle
            of WS-*) is that there was no per-resource metadata about the
            atomicity, and no guarantee that all servers worked the same.

            the nice thing about doing bulk operations as a sequence of requests
            is that you can be sure that
            -the bulk operation is not atomic
            -if one operation fails, everything you havent yet pushed out wont
            have gone through
            -state changes are observable to others during the sequence of operations.
            -the single update code path==the bulk update code path
            It may not be the exact behaviour you want, but at least you can be
            sure that it will be consistent, that no server updates will suddenly
            change their behaviour without you noticing. Which is good, as it is
            surprisingly hard to write tests to determine exactly what the bulk
            update semantics of a remote system are.

            -steve
          • Subbu Allamaraju
            I agree. ... Exactly, that is why I compared this to SOAP. ... Well said. Subbu
            Message 5 of 19 , May 7, 2008
            • 0 Attachment
              I agree.

              > 1. There is some bulk operation in WebDAV, which then requires the
              > notion of partial failure to come back in the response; a simple
              > single error code is no longer enough

              Exactly, that is why I compared this to SOAP.

              > 2. WS-ResourceFramework, while near the pinnacle of WS-*, tried to
              > retrofit bulk operations to its resource-model-atop-SOAP world view,
              > and again, got into a mess about atomicity of updates as well as
              > failures. What I dont like about it (apart from it being the pinnacle
              > of WS-*) is that there was no per-resource metadata about the
              > atomicity, and no guarantee that all servers worked the same.
              >

              :)

              > the nice thing about doing bulk operations as a sequence of requests
              > is that you can be sure that
              > -the bulk operation is not atomic
              > -if one operation fails, everything you havent yet pushed out wont
              > have gone through
              > -state changes are observable to others during the sequence of
              > operations.
              > -the single update code path==the bulk update code path
              > It may not be the exact behaviour you want, but at least you can be
              > sure that it will be consistent, that no server updates will suddenly
              > change their behaviour without you noticing. Which is good, as it is
              > surprisingly hard to write tests to determine exactly what the bulk
              > update semantics of a remote system are.

              Well said.

              Subbu
            Your message has been successfully submitted and would be delivered to recipients shortly.