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

Re: [rest-discuss] Extending request "conversational meaning"

Expand Messages
  • António Mota
    Hi Bill, thanks for your response. However I don t think I understand what you mean. On one side, afaik in HTTP1.1 all connections are keep-alive unless a
    Message 1 of 17 , Aug 3, 2009
    • 0 Attachment
      Hi Bill, thanks for your response. However I don't think I understand
      what you mean. On one side, afaik in HTTP1.1 all connections are
      keep-alive unless a Connection: close comes with the response.

      But nevertheless we are *not* tunneling other protocols over HTTP, we
      are using JMS, IMAP, JCR and intraVM connectors on their respective
      protocols, we just had to "model" our uniform interface around the
      HTTP one for obvious reasons. All these connectors connects to a
      Resource that extracts the relevant information and dispatch the
      request to the specified service and returns the response using the
      original transport protocol.

      So basically the question here is, is it better to extend the Uniform
      Interface adding a LISTEN verb (that will originate a Not Supported
      where appropriate) or using the Headers to signal that, using a
      GET+Connection: keep-listening that should behave like a normal GET
      when the header is not understood by the resource?

      I think this later is preferable, but I would like to ear other opinions.

      Cheers.

      2009/7/31 Bill Burke <bburke@...>:
      > Doesn't HTTP Keep-Alive handle this scenario?  Then the listener would
      > continually being doing GETs (or POSTs).  Its a little less efficient, but
      > does this small CPU savings really save anything?  Then you wouldn't be
      > tunneling any special protocol over HTTP (which is what this would be).
      >
      > António Mota wrote:
      >>
      >>
      >> Our current REST-like infrastructure was designed from the ground-up to
      >> support several connectors, and we have at the moment HTTP, IMAP, JMS
      >> and IntraVM connectors.
      >>
      >> We are now rewriting the JMS connector to extends it to some of the
      >> JMS-specific capabilities, but in a way that is really
      >> connector-specific and not resource or server-side specific. Let me give
      >> a example:
      >>
      >> GET /notifications/toni HTTP/1.0
      >>
      >> This will return a list of all the notifications for Toni. This is a
      >> simple send/receive conversation. But on the JMS side we want to extend
      >> the conversation to use some JMS specific features, namely a
      >> conversation of type listen-receive-keeplistening.
      >>
      >> How to do that in a restfull way? Extending our interface by using
      >> another verb?
      >>
      >> GET /notifications/toni JMS/2.0
      >> LISTEN /notifications/toni JMS/2.0
      >>
      >> By promoting the "listen" to a resource on it's own?
      >>
      >> GET /notifications/toni JMS/2.0
      >> GET /notifications/listener/toni JMS/2.0
      >>
      >> By using General-Headers? Or other type of headers?
      >>
      >> GET /notifications/toni JMS/2.0
      >>
      >> GET /notifications/toni JMS/2.0
      >> Connect: keep-listening
      >>
      >> assuming in this last one that if a resource doesen't understand
      >> "keep-listening" it will ignore it?
      >>
      >> My preference goes to this last one, but I'll like to know what others
      >> think.
      >>
      >> Cheers.
      >>
      > --
      > Bill Burke
      > JBoss, a division of Red Hat
      > http://bill.burkecentral.com
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.