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.
