You cannot post messages because only members can post, and you are not currently a member.
Description:
This is a specification effort put out by the rest-star.org community. It defines a RESTful interface for publish and subscribe and point to point protocols.
|
|
|
Draft 4
|
| |
Filled out rest of protocol. I still want to have a summary page that
gives a clear simple picture of the resources and relationships.
[link]
|
|
|
2-phase ack
|
| |
We need a 2-phase ack to allow for atomicity with a polling consumer
and its own local resources. I'm wondering though if the spec should
define its own protocol, or, it should work with interactions/media
types defined by the transaction spec.
I guess an ack resource could have/share the same media type as a... more »
|
|
|
Queue pull consumer acknowledgement
|
| |
Here's what I've come up with for pull acknowledgement. 1. Consumer does a POST to queue to consume a message ----> Response HTTP/1.1 200 OK Link: </myqueue/messages/111/ack;eta g=1>; rel=acknowledgement Content-Type: whatever the mesage is body The consumer receives the message with an acknowledgement link. Client... more »
|
|
|
New REST-* Messaging Draft
|
| |
After prototyping, I'm back to writing another draft. This is a little bit more formal draft. I created a OSS project at: [link] A draft of the PDF is at: [link] (You'll have to click through an additional link that is *very* long).... more »
|
|
|
queue consumer polling
|
| |
I did a preliminary prototype of a "pull" model for a RESTful queue consumer. [link] Here's how it works: 1) There is no session created for a remote consumer. 2) Consumer clients poll on a specific URL with a POST, i.e.... more »
|
|
|
batching
|
| |
For batching I'm thinking that a "destination" would have a "batch" link for sending and a "feed" link for receiving. A "batch" or "feed" link would accept/return an Atom feed or a multipart/mixed. Each entry in a multipart/mixed would have a set of REST-* specific headers attached to it where appropriate. These custom... more »
|
|
|
Prototype available
|
| |
I wrote a very simple, in-memory, non-reliable prototype of the "pull" topic model. svn co [link] resteasy It depends on resteasy-jaxrs 1.2.GA which is not yet released, so you have to build jax-rs first. Its based on hornetq embedded. If anybody is interested in helping to... more »
|
|
|
Why not copying WS-Notification for PubSub
|
| |
Why reinventing the PubSub wheel once again?
The WS-* eventing battlefield is a nightmare because WS-Eventing and
WS-Notification have been fighting for ever with not decent outcome.
However, technically speaking, WS-Notification does all the
interesting things: Topics tree, BrokeredNotification, Push &... more »
|
|
|
Webhooks
|
| |
It seems to me this spec could benefit from and contribute to the
webhook movement. The idea is essentially what pubsubhubbub is based
on, where new messages are POSTed to a URL you register as a
subscriber. There are HUGE implications of this. However, PubSubHubbub
is currently the only spec working out a way to register webhooks.... more »
|
|
|
|
