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

Anyone interested? (long)

Expand Messages
  • Seairth Jacobs
    I have been kicking around the idea of creating a simple, distributed, message system using REST practices. I know that there are some such things out there
    Message 1 of 5 , Mar 26, 2003
    • 0 Attachment
      I have been kicking around the idea of creating a simple, distributed, message system using REST practices.  I know that there are some such things out there already, but I am looking for extreme simplicity.  The fundamental goal is to see if I can replace my SMTP/POP3 application with something RESTful.  It must be simple and easy to implement.  I expect to whip an initial version in PHP in a few evenings...
       
      And I'm looking for a few good RESTifarians to join me.  For those of you who might be interested, read over the following initial noodlings of mine.  If I can build enough interest, I'll see about setting up a dedicated YahooGroup or site or something.
       
       
      Suppose two parties want to send each other messages.  Each party has a URI that identifies themselves.  This would be similar to an e-mail address.  For illustration purposes, the following URIs are used:
       
       
      Now, suppose I want to send a message to bob.  I would take the following steps:
       
      1) Create a Message on my server and assign a URI to it. (e.g. http://example.invalid/users/seairth/msg/1234)
      2) Send a POST request to bob's URI.  The content-type could be any number of formats, but I will use XML for readability sake:
       
          <notification>
              <from uri="http://example.invalid/users/seairth"
                    name="Seairth Jacobs"/>
              <message uri="http://example.invalid/users/seairth/msg/1234"
                       subject="Is this RESTful?"
                       reply-uri="http://example.invalid/users/seairth/msg/1234"/>
          </notification>
       
      3) bob's server examines the notification and accepts or rejects it.  Acceptance would be performed with a 202 (Accepted) response, while rejection would happen with a 403 (Forbidden) response.  It would also be possible to return a 400 (Bad Request) if bob's server failed to understand the notification well enough to accept or reject it.
       
      4) Suppose bob's server has accepted a URI from me.  Later, bob starts up his client and uses the URI to get the actual message.
       
      That's it.  Done.
       
      Now for some additional details:
       
      -------------------
      In the above notification, the following is optional:
       
      * The "name" attribute of the from element: the friendly name can be provided as an aid.  However, the only authoritative attribute is "uri".
       
      * The "reply-uri" attribute of the message element: if not given, then the "from" element's "uri" attribute MUST be used for all replies to that message.  If given, then "reply-uri" MUST be used for all replies to that message.
       
      -------------------
      Additional notes:
       
      *   The value of the "reply-uri" attribute does not need to match either the "from" element's "uri" attribute or the "message" element's "uri" attribute.  In the above example reply-uri" could have just as easily been "http://example.invalid/users/seairth/reply/1234".  The purpose for a separate reply URI is to allow chaining of messages (i.e. message threads).
       
      * While there is no technical limit on any of the values, the recipient may reject a notification if any value is longer than can be handled. This should be done with the 400 (Bad Request) response, not 403 (Forbidden).
       
      * In order to validate that the message URI was in fact sent by the from-URI, the recipient MAY submit a specific POST message to the from-uri to validate it.  Further details below.
       
      * The recipient MUST NOT access the resource until the notification has been dealt with.  The sender MAY not provide access until the notification is accepted.
       
      * Acceptance of a notification does not mean that the recipient will retrieve the message.  It only indicates that the recipient acknowledged the request.
       
      * The subject is nothing more than a very short (one-liner) excerpt to give the recipient an idea of what the message is about.
       
      * The recipient may reject a notification due to a value given.  For instance, if the "from" element's "uri" attribute value is being "blocked", the recipient may reject the notification outright.  Any such refusal MUST be done with the 403 (Forbidden) response.  The recipient may optionally choose to indicate in the response why the notification was rejected.
       
      * If the notification is accepted, a 202 (Accepted) response MUST be used.  The recipient may optionally choose to return an entity, but the sender is not required to process any such entity.
       
      * Note that it would be possible to send messages of URIs that the sender did not create.  For instance, I could have sent bob a link to an interesting CNN report or some such, as long as that thing has a URI.
       
      * Obviously, the message does not need to be HTML.  It could be any sort of format.  If desired, the recipient can use HEAD on the resource to determine specifics.
       
      * Because the resource (when created by the sender) is always on the sender's server, additional features are available that are not available in traditional "push" style message systems.  For instance, spelling mistakes can be corrected.  Messages can be deleted before your boss discovers what you really think of him, etc.  Obviously, once a recipient performs a GET on a resource, they have a copy... mistakes and all.
       
      -------------------
      Validating Notifications:
       
      Obviously, it would be possible from someone to submit a notification claiming to be someone they are not.  This is a common problem in SMTP, which is partly why spam is so wide-spread (no accountability).  However, this can be easily remedied by asking the supposed sender if they really did send the notification.  For instance, suppose bob were to be suspicious of my notification. He would then take the following steps:
       
      1) Post to my URI the following (again in XML for convenience):
       
          <notification-query>
              <message uri="http://example.invalid/users/seairth/msg/1234"/>
              <to uri="="http://sample.invalid/members/bob" />
          </notification-query>
       
      2) My server would either recognize the combination and return a
      204 (No Content), or returned 400 (Bad Request) to indicate that it's not recognized.
       
       
      Note:  If the message URI contains the from URI as its root (as in my original example), the probability is pretty good that the sender really did create the messages. 
       
      -------------------
      Notification Issues:
       
      One of the bits that I haven't yet worked out is how to ensure that only the intended recipient can retrieve the resource.  I have some thoughts on this (mostly using HTTP Authentication in various ways), but I'll put that off until I see if there's any interest out there...
       
       
      So...  Anyone interested?
       
      ---
      Seairth Jacobs
      seairth@...
    • Yannick Loiseau
      I m currently trying to code such a thing, after i ve red the Paul s proposal [1]. As this protocol need both server to use it, and as I m trying this for a
      Message 2 of 5 , Mar 27, 2003
      • 0 Attachment
        I 'm currently trying to code such a thing, after i've red the Paul's proposal [1]. As this protocol need both server to use it, and as I'm trying this for a personnal purpose, I actually code an IMAP/SMTP <=> HTTP gateway, which is like a webmail client, but returning XML (RSS 1.00 for boxes and mails listing, and XMTP[2] for the messages). Only the Get part is done yet, but the gateway deals with imap, pop3 and nntp... (coded in python under apache/mod_py). I'm doing a client (wxPython) to deal with such a server...
         
         
        ----- Original Message -----
        Sent: Thursday, March 27, 2003 5:17 AM
        Subject: [rest-discuss] Anyone interested? (long)

        I have been kicking around the idea of creating a simple, distributed, message system using REST practices.  I know that there are some such things out there already, but I am looking for extreme simplicity.  The fundamental goal is to see if I can replace my SMTP/POP3 application with something RESTful.  It must be simple and easy to implement.  I expect to whip an initial version in PHP in a few evenings...
         
        And I'm looking for a few good RESTifarians to join me.  For those of you who might be interested, read over the following initial noodlings of mine.  If I can build enough interest, I'll see about setting up a dedicated YahooGroup or site or something.
         
         
        Suppose two parties want to send each other messages.  Each party has a URI that identifies themselves.  This would be similar to an e-mail address.  For illustration purposes, the following URIs are used:
         
         
        Now, suppose I want to send a message to bob.  I would take the following steps:
         
        1) Create a Message on my server and assign a URI to it. (e.g. http://example.invalid/users/seairth/msg/1234)
        2) Send a POST request to bob's URI.  The content-type could be any number of formats, but I will use XML for readability sake:
         
            <notification>
                <from uri="http://example.invalid/users/seairth"
                      name="Seairth Jacobs"/>
                <message uri="http://example.invalid/users/seairth/msg/1234"
                         subject="Is this RESTful?"
                         reply-uri="http://example.invalid/users/seairth/msg/1234"/>
            </notification>
         
        3) bob's server examines the notification and accepts or rejects it.  Acceptance would be performed with a 202 (Accepted) response, while rejection would happen with a 403 (Forbidden) response.  It would also be possible to return a 400 (Bad Request) if bob's server failed to understand the notification well enough to accept or reject it.
         
        4) Suppose bob's server has accepted a URI from me.  Later, bob starts up his client and uses the URI to get the actual message.
         
        That's it.  Done.
         
        Now for some additional details:
         
        -------------------
        In the above notification, the following is optional:
         
        * The "name" attribute of the from element: the friendly name can be provided as an aid.  However, the only authoritative attribute is "uri".
         
        * The "reply-uri" attribute of the message element: if not given, then the "from" element's "uri" attribute MUST be used for all replies to that message.  If given, then "reply-uri" MUST be used for all replies to that message.
         
        -------------------
        Additional notes:
         
        *   The value of the "reply-uri" attribute does not need to match either the "from" element's "uri" attribute or the "message" element's "uri" attribute.  In the above example reply-uri" could have just as easily been "http://example.invalid/users/seairth/reply/1234".  The purpose for a separate reply URI is to allow chaining of messages (i.e. message threads).
         
        * While there is no technical limit on any of the values, the recipient may reject a notification if any value is longer than can be handled. This should be done with the 400 (Bad Request) response, not 403 (Forbidden).
         
        * In order to validate that the message URI was in fact sent by the from-URI, the recipient MAY submit a specific POST message to the from-uri to validate it.  Further details below.
         
        * The recipient MUST NOT access the resource until the notification has been dealt with.  The sender MAY not provide access until the notification is accepted.
         
        * Acceptance of a notification does not mean that the recipient will retrieve the message.  It only indicates that the recipient acknowledged the request.
         
        * The subject is nothing more than a very short (one-liner) excerpt to give the recipient an idea of what the message is about.
         
        * The recipient may reject a notification due to a value given.  For instance, if the "from" element's "uri" attribute value is being "blocked", the recipient may reject the notification outright.  Any such refusal MUST be done with the 403 (Forbidden) response.  The recipient may optionally choose to indicate in the response why the notification was rejected.
         
        * If the notification is accepted, a 202 (Accepted) response MUST be used.  The recipient may optionally choose to return an entity, but the sender is not required to process any such entity.
         
        * Note that it would be possible to send messages of URIs that the sender did not create.  For instance, I could have sent bob a link to an interesting CNN report or some such, as long as that thing has a URI.
         
        * Obviously, the message does not need to be HTML.  It could be any sort of format.  If desired, the recipient can use HEAD on the resource to determine specifics.
         
        * Because the resource (when created by the sender) is always on the sender's server, additional features are available that are not available in traditional "push" style message systems.  For instance, spelling mistakes can be corrected.  Messages can be deleted before your boss discovers what you really think of him, etc.  Obviously, once a recipient performs a GET on a resource, they have a copy... mistakes and all.
         
        -------------------
        Validating Notifications:
         
        Obviously, it would be possible from someone to submit a notification claiming to be someone they are not.  This is a common problem in SMTP, which is partly why spam is so wide-spread (no accountability).  However, this can be easily remedied by asking the supposed sender if they really did send the notification.  For instance, suppose bob were to be suspicious of my notification. He would then take the following steps:
         
        1) Post to my URI the following (again in XML for convenience):
         
            <notification-query>
                <message uri="http://example.invalid/users/seairth/msg/1234"/>
                <to uri="="http://sample.invalid/members/bob" />
            </notification-query>
         
        2) My server would either recognize the combination and return a
        204 (No Content), or returned 400 (Bad Request) to indicate that it's not recognized.
         
         
        Note:  If the message URI contains the from URI as its root (as in my original example), the probability is pretty good that the sender really did create the messages. 
         
        -------------------
        Notification Issues:
         
        One of the bits that I haven't yet worked out is how to ensure that only the intended recipient can retrieve the resource.  I have some thoughts on this (mostly using HTTP Authentication in various ways), but I'll put that off until I see if there's any interest out there...
         
         
        So...  Anyone interested?
         
        ---
        Seairth Jacobs
        seairth@...


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



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • S. Alexander Jacobson
        I am interested in this as well, but, as we discussed earlier, it faces the difficulty of retrieving only new messages. Assuming, we follow Roy Fielding s
        Message 3 of 5 , Mar 27, 2003
        • 0 Attachment
          I am interested in this as well, but, as we
          discussed earlier, it faces the difficulty of
          retrieving only "new" messages.

          Assuming, we follow Roy Fielding's reccomdendation
          and view a mailbox as a container for
          messages/notifications, we need a way to query for
          all messages since the last time the client
          checked.

          Here are some approaches and their issues:
          1. Modify the server's state each time the client
          checks for messages, but that prevents multiple
          clients from sharing the same mailbox without
          proliferating server state and it also prevents
          the same user from going back to a prior state
          without substantial added complexity.

          2. Use a parametrized URL, like:

          GET /getNewNotifications?since=UID

          where UID is the unique identifier of the last
          message retrieved, but this seems unRESTful in
          that this URL is not really opaque (In the
          Wiki Jeff Bone appears to argue that this is ok,
          so I am not really sure, but to me it feels
          unRESTful)

          3. Use a single range headers against a single
          mailbox URL, but that prohibits you from changing
          the representation of the underlying mailbox. If
          we want the server periodically to check
          availability of actual messages and update on that
          basis, we can't use range headers.

          4. Use multipart-byteranges.
          I think this is the best option, but a. most
          clients don't suppport it and b. it verges on
          specification abuse.

          A much more useful way to go would be for the HTTP
          authors not to have used bytes as the only units
          for range headers. If HTTP allowed range headers
          to be specified in application units e.g. records,
          then this would all be very easy. Unfortunately,
          they didn't and we have HTTP as it currently
          stands.

          -Alex-

          ___________________________________________________________________
          S. Alexander Jacobson i2x Media
          1-212-787-1914 voice 1-603-288-1280 fax








          On Wed, 26 Mar 2003, Seairth Jacobs wrote:

          > I have been kicking around the idea of creating a simple, distributed, message system using REST practices. I know that there are some such things out there already, but I am looking for extreme simplicity. The fundamental goal is to see if I can replace my SMTP/POP3 application with something RESTful. It must be simple and easy to implement. I expect to whip an initial version in PHP in a few evenings...
          >
          > And I'm looking for a few good RESTifarians to join me. For those of you who might be interested, read over the following initial noodlings of mine. If I can build enough interest, I'll see about setting up a dedicated YahooGroup or site or something.
          >
          >
          > Suppose two parties want to send each other messages. Each party has a URI that identifies themselves. This would be similar to an e-mail address. For illustration purposes, the following URIs are used:
          >
          > http://example.invalid/users/seairth
          > http://sample.invalid/members/bob
          >
          > Now, suppose I want to send a message to bob. I would take the following steps:
          >
          > 1) Create a Message on my server and assign a URI to it. (e.g. http://example.invalid/users/seairth/msg/1234)
          > 2) Send a POST request to bob's URI. The content-type could be any number of formats, but I will use XML for readability sake:
          >
          > <notification>
          > <from uri="http://example.invalid/users/seairth"
          > name="Seairth Jacobs"/>
          > <message uri="http://example.invalid/users/seairth/msg/1234"
          > subject="Is this RESTful?"
          > reply-uri="http://example.invalid/users/seairth/msg/1234"/>
          > </notification>
          >
          > 3) bob's server examines the notification and accepts or rejects it. Acceptance would be performed with a 202 (Accepted) response, while rejection would happen with a 403 (Forbidden) response. It would also be possible to return a 400 (Bad Request) if bob's server failed to understand the notification well enough to accept or reject it.
          >
          > 4) Suppose bob's server has accepted a URI from me. Later, bob starts up his client and uses the URI to get the actual message.
          >
          > That's it. Done.
          >
          > Now for some additional details:
          >
          > -------------------
          > In the above notification, the following is optional:
          >
          > * The "name" attribute of the from element: the friendly name can be provided as an aid. However, the only authoritative attribute is "uri".
          >
          > * The "reply-uri" attribute of the message element: if not given, then the "from" element's "uri" attribute MUST be used for all replies to that message. If given, then "reply-uri" MUST be used for all replies to that message.
          >
          > -------------------
          > Additional notes:
          >
          > * The value of the "reply-uri" attribute does not need to match either the "from" element's "uri" attribute or the "message" element's "uri" attribute. In the above example reply-uri" could have just as easily been "http://example.invalid/users/seairth/reply/1234". The purpose for a separate reply URI is to allow chaining of messages (i.e. message threads).
          >
          > * While there is no technical limit on any of the values, the recipient may reject a notification if any value is longer than can be handled. This should be done with the 400 (Bad Request) response, not 403 (Forbidden).
          >
          > * In order to validate that the message URI was in fact sent by the from-URI, the recipient MAY submit a specific POST message to the from-uri to validate it. Further details below.
          >
          > * The recipient MUST NOT access the resource until the notification has been dealt with. The sender MAY not provide access until the notification is accepted.
          >
          > * Acceptance of a notification does not mean that the recipient will retrieve the message. It only indicates that the recipient acknowledged the request.
          >
          > * The subject is nothing more than a very short (one-liner) excerpt to give the recipient an idea of what the message is about.
          >
          > * The recipient may reject a notification due to a value given. For instance, if the "from" element's "uri" attribute value is being "blocked", the recipient may reject the notification outright. Any such refusal MUST be done with the 403 (Forbidden) response. The recipient may optionally choose to indicate in the response why the notification was rejected.
          >
          > * If the notification is accepted, a 202 (Accepted) response MUST be used. The recipient may optionally choose to return an entity, but the sender is not required to process any such entity.
          >
          > * Note that it would be possible to send messages of URIs that the sender did not create. For instance, I could have sent bob a link to an interesting CNN report or some such, as long as that thing has a URI.
          >
          > * Obviously, the message does not need to be HTML. It could be any sort of format. If desired, the recipient can use HEAD on the resource to determine specifics.
          >
          > * Because the resource (when created by the sender) is always on the sender's server, additional features are available that are not available in traditional "push" style message systems. For instance, spelling mistakes can be corrected. Messages can be deleted before your boss discovers what you really think of him, etc. Obviously, once a recipient performs a GET on a resource, they have a copy... mistakes and all.
          >
          > -------------------
          > Validating Notifications:
          >
          > Obviously, it would be possible from someone to submit a notification claiming to be someone they are not. This is a common problem in SMTP, which is partly why spam is so wide-spread (no accountability). However, this can be easily remedied by asking the supposed sender if they really did send the notification. For instance, suppose bob were to be suspicious of my notification. He would then take the following steps:
          >
          > 1) Post to my URI the following (again in XML for convenience):
          >
          > <notification-query>
          > <message uri="http://example.invalid/users/seairth/msg/1234"/>
          > <to uri="="http://sample.invalid/members/bob" />
          > </notification-query>
          >
          > 2) My server would either recognize the combination and return a 204 (No Content), or returned 400 (Bad Request) to indicate that it's not recognized.
          >
          >
          > Note: If the message URI contains the from URI as its root (as in my original example), the probability is pretty good that the sender really did create the messages.
          >
          > -------------------
          > Notification Issues:
          >
          > One of the bits that I haven't yet worked out is how to ensure that only the intended recipient can retrieve the resource. I have some thoughts on this (mostly using HTTP Authentication in various ways), but I'll put that off until I see if there's any interest out there...
          >
          >
          > So... Anyone interested?
          >
          > ---
          > Seairth Jacobs
          > seairth@...
        • Erik Terpstra
          ... I am not sure if I understand you correctly. But if the issue here is to retrieve only new messages instead of the entire inbox on the specified
          Message 4 of 5 , Mar 27, 2003
          • 0 Attachment
            S. Alexander Jacobson wrote:
            > I am interested in this as well, but, as we
            > discussed earlier, it faces the difficulty of
            > retrieving only "new" messages.

            <snip>

            I am not sure if I understand you correctly. But if the issue here is to
            retrieve only new messages instead of the entire inbox on the specified
            resource (i.e. a bandwidth/efficiency issue), you can use rproxy (or
            rproxy like functionality) in your server.

            http://rproxy.samba.org

            --Erik
          • Roy T. Fielding
            ... It is not unRESTful. Every resource should have a URI. That is a resource, even if it is ephemeral in content. ... It also ties the client and server
            Message 5 of 5 , Mar 27, 2003
            • 0 Attachment
              > 2. Use a parametrized URL, like:
              >
              > GET /getNewNotifications?since=UID
              >
              > where UID is the unique identifier of the last
              > message retrieved, but this seems unRESTful in
              > that this URL is not really opaque (In the
              > Wiki Jeff Bone appears to argue that this is ok,
              > so I am not really sure, but to me it feels
              > unRESTful)

              It is not unRESTful. Every resource should have a URI. That is a
              resource, even if it is ephemeral in content.

              > 3. Use a single range headers against a single
              > mailbox URL, but that prohibits you from changing
              > the representation of the underlying mailbox. If
              > we want the server periodically to check
              > availability of actual messages and update on that
              > basis, we can't use range headers.
              >
              > 4. Use multipart-byteranges.
              > I think this is the best option, but a. most
              > clients don't suppport it and b. it verges on
              > specification abuse.

              It also ties the client and server implementations together,
              which is definitely contrary to REST.

              > A much more useful way to go would be for the HTTP
              > authors not to have used bytes as the only units
              > for range headers. If HTTP allowed range headers
              > to be specified in application units e.g. records,
              > then this would all be very easy. Unfortunately,
              > they didn't and we have HTTP as it currently
              > stands.

              Sorry, but you are wrong on both accounts. Read section 3.12
              of RFC 2616. In any case, a range request is not an appropriate
              solution to this problem because it ties the client and server
              implementations together. If you don't care about that, then
              just use rsync as your protocol. It is more efficient.

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