[zeromq-dev] REST over ZeroMQ

Michael Powell mwpowellhtx at gmail.com
Tue Feb 10 13:39:32 CET 2015


On Tue, Feb 10, 2015 at 5:44 AM, Pieter Hintjens <ph at imatix.com> wrote:
> 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.

Exactly; in REST verbiage parlance.

> 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.

Definitely, two different paradigms.

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

Correct; they don't need to, but it is often helpful when they do.

> 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.

Up to the REST designer IMO. Verbosity, that's up to the designer how
concise an API can be generated. Back-end services and controllers
don't need to be parallel, but are frequently as such, what with MVC,
TPL, and other parallel constructs available in the REST world.

Batch or other could be considered a POST-able payload, for instance.

> -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
> _______________________________________________
> 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