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