I'm currently involved in the design phase of a HTTP-based API for a Messaging-type project. The system is primary composed of service-oriented loosely-coupled heterogeneous daemons talking to each other via HTTP.
Each daemon handles HTTP requests and responds appropriately whether a submitted message was processed or not. At the same time, on certain events during the time the message is being processed/cosumed, it is allowed for the daemon to emit callbacks in the form of webhooks / HTTP push.
To illustrate:
+-----+ pushes [1] +-----+ pushes [3] +-----+
| | message X | | message Y | |
| A |--------------->| B |---------------->| C |
| |<---------------| |<----------------| |
+-----+ 200 OK [2] +-----+ 200 OK [4] +-----+
= message Y was pushed to C because B encountered it when processing X
= message Y is was supplied by A, or at least generated from X.
= the timing of events [2] and [3]-[4] is not dependent on each other.
Notes:
- HTTP was chosen over a particular MOM-style protocol (e.g. Stomp, AMQP) in order to decouple the services (daemons) from a being a queuing, broker-centric design. Think broker-less, peer-to-peer messaging where a broker is optional.
Question:
- How do we define/represent an HTTP push/webhook as a string; i.e. we prefer that somewhere in message X as in our example, we'd like to define message Y in a simplest string form such as: "GET /path/in/C?qstr=foobar"
- GET is easily representable but GET is not idempotent and mostly the daemon processing themselves causes side effects so pushes happen as POST mostly. Is there a standard in specifying an HTTP POST as simple a "GET /anything HTTP/1.1"?
- Our message bodies are simple JSON format but we'd probably support a plain querystring parameters. Would "POST /path/here?with=querystring" with a Content-Length zero (i.e. empty body) suffice?
- Do we have to invent our own DSL for this? We'd prefer to at least support GET, POST. Perhaps PUT,DELETE can easily be treated like GET given they are idempotent?
Thanks!