[zeromq-dev] REST over ZeroMQ

Pieter Hintjens ph at imatix.com
Tue Feb 10 12:44:04 CET 2015


Been thinking about this...

Let's take positions.

So a resource model could be: account (held by an individual) contains
positions and orders. Positions perhaps also contain orders. To create
a new position or order, you POST into the account. To place a stop
loss order on a position, you POST the order to the position. To close
a position you GET the position and then PUT the position with 'status
= "closed"' or whatever. To cancel an order you might GET the order
and then DELETE it.

Resource vs. object + methods is just a matter of model design. Once
you abandon a model based on methods, and move to a model based on
resources and properties, it generally falls into place.

The resources do not necessarily map to real data; often they're a
virtual API that is interpreted by the server.

My main objection to a RESTful API is low performance due to verbose
formats, round-tripping, and lack of real async flows. However I think
it makes sense for lower-volume higher-complexity cases, especially if
you can do the high volume work via another protocol.

-Pieter

On Mon, Feb 9, 2015 at 7:09 PM, Gregg Irwin <gregg at pointillistic.com> wrote:
> DS> When something is a pure resource I try to design a RESTful
> DS> service but with something like position I prefer to have commands
> DS> like ClosePositionCommand, UpdateStopLossCommand, etc...
>
> AFAIK, nobody has solved the REST+actions dilemma. There is no
> consensus. REST is about pure resources. You can add path elements
> that are actions, have a generic /action segment and use the body
> to pass data, or use query strings. To be truly RESTful, clients need
> to manipulate resources.
>
> -- Gregg
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list