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

Server side verification

Expand Messages
  • Stefano Masini
    Hi, given the great answers to my previous question, I ll come up with another one, so you guys can keep teaching me REST. :) Let s say I want to PUT some HTML
    Message 1 of 3 , May 4, 2008
    • 0 Attachment
      Hi,

      given the great answers to my previous question, I'll come up with
      another one, so you guys can keep teaching me REST. :)

      Let's say I want to PUT some HTML to a given url. This HTML is being
      edited by a human being using a wordeditor like TinyMCE, FCKEditor,
      Kupu, or whatever.
      When I click on "Save", a PUT request is fired containing the HTML.
      The server updates its internal state, and replies ok. At the next
      GET, I'll see the HTML I just sent.

      Now let's say that the server needs to do some html cleanup, like
      stripping some tags, or modifying some attributes. This might be done
      in the PUT request handler, just before updating the internal state,
      so that I store the cleaned up version. Fine. When I do GET, I'll see
      the cleaned up version.

      Now, let's say that I want to support another button: "Cleanup". This
      button cleans up the currently edited content, but doesn't save it on
      the server yet. It's useful because I might be working on a "dirty"
      html for a long time, and I need to clean it up from time to time
      before finally saving. Unfortunately only the server knows how to
      clean it up, so the operation could never be performed in javascript
      by my browser.

      How does this last requirement fit inside the REST view of the world?
      Up to the last point it looked like a very simple problem of putting
      and getting a resource.
      But if I just want a simple "Cleanup" button, all of a sudden this
      looks so much like RPC. So? I'm a little confused. Should I just say
      that this part of my application doesn't fit the REST assumptions, so
      it doesn't even make sense talking about it? Or does it make sense to
      consider it under a different light?

      Thanks a lot!
      Stefano
    • Eric J. Bowman
      ... It fits in just fine. POST your draft to the real URL for your document instead of using PUT. Clean up the submitted HTML in whatever way the server
      Message 2 of 3 , May 4, 2008
      • 0 Attachment
        >
        > How does this last requirement fit inside the REST view of the world?
        > Up to the last point it looked like a very simple problem of putting
        > and getting a resource.
        > But if I just want a simple "Cleanup" button, all of a sudden this
        > looks so much like RPC. So? I'm a little confused. Should I just say
        > that this part of my application doesn't fit the REST assumptions, so
        > it doesn't even make sense talking about it? Or does it make sense to
        > consider it under a different light?
        >

        It fits in just fine. POST your draft to the real URL for your
        document instead of using PUT. Clean up the submitted HTML in whatever
        way the server would if the method were PUT. You can return the result
        at the real URL for your document, but with '.draft' appended, or
        '/draft', whatever floats your boat. Nothing like RPC.

        -Eric
      • Subbu Allamaraju
        In other words, the server will create a new draft resource, and send its location via the Location header in response. Subsequently, the client can PUT the
        Message 3 of 3 , May 5, 2008
        • 0 Attachment
          In other words, the server will create a new draft resource, and send
          its location via the Location header in response. Subsequently, the
          client can PUT the draft version for further clan up.

          But, what benefits does the server get in supporting such an
          implementation?

          Subbu

          On May 4, 2008, at 2:59 PM, Eric J. Bowman wrote:
          >>
          >> How does this last requirement fit inside the REST view of the world?
          >> Up to the last point it looked like a very simple problem of putting
          >> and getting a resource.
          >> But if I just want a simple "Cleanup" button, all of a sudden this
          >> looks so much like RPC. So? I'm a little confused. Should I just say
          >> that this part of my application doesn't fit the REST assumptions, so
          >> it doesn't even make sense talking about it? Or does it make sense to
          >> consider it under a different light?
          >>
          >
          > It fits in just fine. POST your draft to the real URL for your
          > document instead of using PUT. Clean up the submitted HTML in
          > whatever
          > way the server would if the method were PUT. You can return the
          > result
          > at the real URL for your document, but with '.draft' appended, or
          > '/draft', whatever floats your boat. Nothing like RPC.
          >
          > -Eric
        Your message has been successfully submitted and would be delivered to recipients shortly.