On Mon, Feb 9, 2015 at 8:01 AM, Doron Somech <[email protected]> wrote: > Thanks. > > Regarding custom routing, then I'm using the same framework but I'm not > really doing RESTful. Now it is more like RPC.
It could be, but I'm not sure there's anything in REST-ful that says there needs to be an object/instance/server behind the call. Usually there is a controller and/or some view/data behind it, at least. Literally 'REST' is 'representational state transfer'. Google 'what is restful api' for more info. > On Mon, Feb 9, 2015 at 3:56 PM, Michael Powell <[email protected]> > wrote: >> >> On Mon, Feb 9, 2015 at 7:50 AM, Doron Somech <[email protected]> wrote: >> > Michael, my point was that I don't think that RESTful is always the >> > right >> > answer. Pieter suggested to stop use RPC and to use RESTful instead. I'm >> > not >> > convinced (but not rejecting) of the idea. I raise a point that I think >> > commands and not presented correctly with RESTful. >> >> I appreciate that perspective, thank you. >> >> It's a different paradigm, with its own sense of verbs, subjects, >> predicates, etc. That's for sure. >> >> That's not to say you couldn't roll your own rest-ful API, but then >> you're doing custom routing and things like this. >> >> > On Mon, Feb 9, 2015 at 3:43 PM, Michael Powell <[email protected]> >> > wrote: >> >> >> >> On Mon, Feb 9, 2015 at 7:40 AM, Doron Somech <[email protected]> >> >> wrote: >> >> > I think this is confusing, I want closing a position to be in the >> >> > language >> >> > of the protocol. It's like design a messaging protocol and sending a >> >> > message >> >> > will be an update to queue... I think. >> >> > >> >> > What about making command a resource as well? (like what Michael >> >> > suggested) >> >> > which actually also affect the Position resource? >> >> >> >> That's really up to the API designer. >> >> >> >> To my knowledge, that sort of thing is beyond the scope of REST-ful >> >> itself. It doesn't tell you (indeed, shouldn't) what your dialect, >> >> 'protocol' should be, beyond a couple of helpful patterns for puts, >> >> gets, posts, etc. >> >> >> >> > On Mon, Feb 9, 2015 at 3:12 PM, Pieter Hintjens <[email protected]> >> >> > wrote: >> >> >> >> >> >> You'd post the position and then add children to it, if you want a >> >> >> history, or put new versions, if you don't want a history... I >> >> >> think. >> >> >> >> >> >> On Feb 9, 2015 1:04 PM, "Doron Somech" <[email protected]> wrote: >> >> >>> >> >> >>> How would you use Position (Financial Trading) as a resource? >> >> >>> >> >> >>> For example, the opening of the position will be a put operation, >> >> >>> but >> >> >>> what about setting stop loss/take profit and/or closing the >> >> >>> position? >> >> >>> All of >> >> >>> them will be Post? >> >> >>> >> >> >>> When something is a pure resource I try to design a RESTful service >> >> >>> but >> >> >>> with something like position I prefer to have commands like >> >> >>> ClosePositionCommand, UpdateStopLossCommand, etc... >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Mon, Feb 9, 2015 at 1:10 PM, Pieter Hintjens <[email protected]> >> >> >>> wrote: >> >> >>>> >> >> >>>> Hi all, >> >> >>>> >> >> >>>> I've published a draft RFC meant to help build RESTful APIs / >> >> >>>> protocols over ZeroMQ: http://hintjens.com/blog:86 >> >> >>>> >> >> >>>> Comments welcome. There is a basic zproto model. >> >> >>>> >> >> >>>> -Pieter >> >> >>>> _______________________________________________ >> >> >>>> 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 >> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> > >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
