[zeromq-dev] REST over ZeroMQ

[Doron Somech]

I'm not sure I fully understand, when you POST into the account you
actually make a update to an account.
So if  the account has for example 100 positions you are going to send it
back with 101 positions?
Now at server side server need to understand what exactly changed in the
account?

My thoughts are:
* When you want to open position you make a PUT to the Position resource
and reference the account id.
* When I want to update stop loss you GET the position and POST it back
with the take profit field changed
* When I want to close a position I change the position status and POST it
back.

The thing I don't like about it is that the server side when I get an
update to a position I need to try to understand what the user really want
to make (set stop loss, close the position, etc...).

Anyway I think commands still have important place when designing a
protocol, maybe we can some how integrate them with the protocol? Still
have resources but we can also send command to a resource and not only an
POST (update).






On Tue, Feb 10, 2015 at 1:44 PM, 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.
>
> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150210/7c3a3c50/attachment.htm>