Thank you very much for very detailed explanation niphlod. Amazing. For me , JSONRPC is more useful in current projects (which do not need CURD , just Update and Read is mostly done ).
For my case it is mostly Machine learning , parsing files , indexing , producing Network diagrams , etc. so that fit this cases : > You don't need a service but some means of communication by a server > written by you and a client that only you use ? I will stick with JSONRPC. On Sat, Mar 2, 2013 at 8:02 PM, Niphlod <niph...@gmail.com> wrote: > it's merely a question about "angles".... > > suppose you want to give access only to one table, e.g., products. only > search by name and return just the quantity in stock in addition to the > name. > > with jsonrpc you need to code a function that searches through your > products and returns a list of tuples (or a dictionary) holding "name, > stock" values. > > Now, suppose you want to add the possibility to order a product, or > multiple ones. > > again, with jsonrpc you need to code a function that searches through your > products and returns a list of tuples holding "name, ordered_qty" values. > > Now, suppose you want to give the ability to search through product tags, > and order products > > you need to come up with a representation of your model, code a function > that searches through tags, links them through products, and then again > return the result. > > In all of this, you need to figure out a result that carries all the info > needed for an API to be used (such as, e.g., returning tags in the 1st > function anyway if they are handy, etc etc etc). > > When you add more and more functionality, or "features", you need to be > consistent in what you return, else your API becomes more and more bloated > and patched and disconnetted from piece to piece. JSONRPC doesn't define > the state of your products, unless you come up with that. You have to tell > your users that order_product method returns "name, ordered_qty" , come up > with an error when they can't order something, tell them that a product can > be searched also by tags with the search_by_tag method, etc etc etc. > > At any given point in time, clients need to know what feature you expose > and what to expect back. > > On the other side, REST uses urls, response codes http verbs (HEAD, GET, > POST, PUT, DELETE) and headers to describe both your returned format and > your model. They know when an operation change something, if they can cache > the result, etc etc. > > In richer and standards conformant APIs you get back with the results also > links to access connected resources (i.e. the details about the tag of the > product). Clients can ask xml or json just changing headers, and generally > must be informed of your model only .... they know already (if your API is > totally REST "certified") that they should use x to achieve y. > > tl;dr: In general, a REST API feels more "open" but yes, more complicated > because it involves several base concepts on how the web works. > JSONRPC on the other end feels more "explicit". JSONRPC in an APIs exposes > more "how to work with" while REST "what to work with". > > So, suppose you want to expose an api to access your online store.... I'd > go for REST hands down. > You need instead to expose a service that returns the avatar picture > location given an email ? JSONRPC. > You need to expose a service that crops pictures sent by users ? ..... > neither (binary formats don't play well with both JSONRPC or REST) > You don't need a service but some means of communication by a server > written by you and a client that only you use ? JSONRPC will be more > productive in a short term and if you have all the detailed implementation > planned, but on the long run REST may be more appropriate. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
