[zeromq-dev] REST over ZeroMQ

[Michael Powell]

On Tue, Feb 10, 2015 at 6:39 AM, Doron Somech <somdoron at gmail.com> wrote:
> 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?

The waters here are muddier IMO. Depends on the API design.

When you PUT, you may be 'posting' (or 'writing') into the account, as well.

AFAIK, all that means is you are engaging the back-end REST service,
and that some state is being handled.

http://www.restapitutorial.com/lessons/httpmethods.html

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

Personally, I'm not saying remote objects don't have a place (or
views, controllers, etc). However, this is purely a whole other
paradigm; i.e. take REST (nevermind ZMQ, for the moment) versus CORBA
versus WCF, for example.

It's been an interesting discussion for my part.

HTH

> 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
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>