RFC: REST-RPC

Discussions

News: RFC: REST-RPC

  1. RFC: REST-RPC (28 messages)

    XML-RPC is a straight-forward protocol, based on the ubiquitous XML and HTTP technologies in a simple request-response model focusing on data communication rather than structure. Although it had some obvious shortcomings, such as lack of Unicode-support, lack of discovery, and reliance on HTTP, the protocol is simple and powerful.

    XML-RPC was considered not to be powerful enough for some uses, so Microsoft and others came up with SOAP, which is more advanced (and complicated) than XML-RPC. In order to apply SOAP effectively, one should also understand and apply quite a few technologies, such as XML Namespaces, UDDI, WSDL, XML Schema, Basic Profile, etc., and that's just the beginning. The stack of Web Services technologies is still growing.

    In typical system-to-system communication scenarios (especially internal, or non-mission-critical scenarios), the complexity of SOAP is plain overkill and simpler interfaces are preferred. The popularity of simple APIs such as the eBay REST API, Yahoo Flickr and Amazon Alexa underline this, as well as the lively discussions on REST.

    REST-RPC aims to strengthen the case for simple RPC applications by providing an extremely protocol based on the ubiquitous HTTP, XML and Unicode technologies. It continues where XML-RPC left off, fixing all of the identified XML-RPC issues and offering more flexibility by supporting HTTP GET and POST. So browsers can call such services directly.

    This protocol is currently part of XINS (Wikipedia), a framework for RPC applications, but we are in the process of making it a technology in its own right. We have been using and improving the protocol in various applications since 2002 and find it is very easy to explain and implement. Compared to SOAP the learning curve is almost a flat line.

    An F.A.Q. page has been set up which aims to explain what REST-RPC is about, step by step:
    http://xins.sourceforge.net/restrpc.html

    If you want to see the protocol in action, either run the XINS Primer tutorial or test drive a public API.

    Comments from the TSS community are highly appreciated!

    Threaded Messages (28)

  2. RPC is dead, long live RPC?[ Go to top ]

    Write on the whiteboard 1,000 times: a web service is not a remote procedure call.

    I am no fonder of SOAP than anyone--as a friend of mine points out, only dirty people wash--but in this day and age, document-oriented interfaces are essential. Real messages are denormalized and hierarchal; PUTs and POSTs cannot be confined to an argument-list paradigm.

    There is much to admire about XINS, a fine piece of work overall; but this is the millstone around your neck.
  3. Re: RPC is dead, long live RPC?[ Go to top ]

    Indeed there is a big difference between a document- and an RPC-oriented approach. Both have their ground. REST-RPC is not document-centric and it's not trying to be a drop-in replacement for SOAP.

    However, it does aim to be a protocol that will be much more convenient than SOAP in those situations where an RPC approach makes sense. And that may turn out to be the largest piece of the pie.

    Out of curiosity: if "there is much to admire about XINS", then what are you referring to exactly?
  4. Re: RPC is dead, long live RPC?[ Go to top ]

    However, it does aim to be a protocol that will be much more convenient than SOAP in those situations where an RPC approach makes sense.

    For situations, where an RPC approach makes sense, there is a mature, proven and highly efficient technologie: CORBA

    http://java.sun.com/j2se/1.5.0/docs/guide/idl/GShome.html

    http://www.corba.org/
  5. CORBA isn't always a good choice[ Go to top ]

    We have a rather tight integration with a business partner on the other side of three firewalls. CORBA with it's long lived connections is a major pain point in that integration. We can't wait until a simple, sessionless, request/response XML interface is exposed to us for this service. YMMV but for us this just isn't an ideal integration technology.
  6. CORBA isn't always a good choice[ Go to top ]

    We have a rather tight integration with a business partner on the other side of three firewalls. CORBA with it's long lived connections is a major pain point in that integration. We can't wait until a simple, sessionless, request/response XML interface is exposed to us for this service. YMMV but for us this just isn't an ideal integration technology.

    So have you looked at XML-RPC and REST-RPC? What do you like or dislike about it?

    Note that compared to XML-RPC, REST-RPC is an evolutionary next step. It aims to be more flexible, it fixes some glitches, reduces overhead and adds some minor features. But in principle the two are similar.
  7. Re: RPC is dead, long live RPC?[ Go to top ]

    However, it does aim to be a protocol that will be much more convenient than SOAP in those situations where an RPC approach makes sense.
    For situations, where an RPC approach makes sense, there is a mature, proven and highly efficient technologie: CORBAhttp://java.sun.com/j2se/1.5.0/docs/guide/idl/GShome.htmlhttp://www.corba.org/

    Be serious. I was talking about a simple protocol. not about a monster. CORBA, the IBM San Fransisco framework and SOAP fit in the same category. You can do powerful things with them, but it comes with a big cost in terms of complexity and bloat. If you are looking for elegance, steer clear.

    XML-RPC is an example of a simple technology, and so is REST-RPC. And simplicity is key to scalable, secure and maintainable architecture. This is one of the key arguments in the whole discussion on REST vs SOAP.
  8. REST != RPC[ Go to top ]

    Ernst,

    That was my point precisely. If people form the impression that REST means "no documents", REST will be discredited.
  9. CORBA is easy[ Go to top ]

    CORBA, the IBM San Fransisco framework and SOAP fit in the same category. You can do powerful things with them, but it comes with a big cost in terms of complexity and bloat.

    CORBA being difficult is a myth. For simple RPC-style calls that just call methods and have some parameters it is very easy to use, the most difficult thing is writing the IDL, which shouldn't be difficult either for somebody knowing Java or C.
    Just have a look at the tutorial link I gave.
    http://java.sun.com/j2se/1.5.0/docs/guide/idl/GShome.html

    And CORBA calls are very fast: I did some benchmarks, between a PC and a Java server running on a mainframe I got about 100ms for a roundtrip call with a huge parameter set of about 200K.
  10. RPC is dead, long live RPC?[ Go to top ]

    --but in this day and age, document-oriented interfaces are essential. Real messages are denormalized and hierarchal;

    -exactly
  11. RPC is dead, long live RPC?[ Go to top ]

    --but in this day and age, document-oriented interfaces are essential. Real messages are denormalized and hierarchal;
    -exactly
    In some situations, indeed. However, in the case of a Google Search API, why do you consider a documented-oriented interface a necessity? An RPC-based approach will typically give you the same results, in less time, with less overhead and with more performance.

    Also, consider automatic code generation. With an RPC-based approach, the mapping is a natural one. That's why XINS has advanced very far in this area. Just because it's quite easy.

    However, with a document-centric approach, how do you map it to a function call? Just pass the whole document? Alternatively, you can have a mapping from a document structure to a function call. But then you again increase the complexity of your system. And that's exactly what I would want to avoid.
  12. RPC is dead, long live RPC?[ Go to top ]

    An RPC-based approach will typically give you the same results, in less time, with less overhead and with more performance.

    Nonsense! A document/literal SOAP message has less overhead than RPC. You are no longer carrying structure and type information in your payload, just the data. Remember, a SOAP header is optional and if you include it, you are not required to put anything into it. Only if you wish to add other stacks to the payload do you add headers. In that case the "overhead" is not due to SOAP; it's due to the additional processing you choose to include. How would you propose to add the features of WS-Security or WS-Addressing using RPC? Whatever you did would add at least as much overhead.
    Also, consider automatic code generation. With an RPC-based approach, the mapping is a natural one.


    The availablity of code generation is hardly an argument. Besides, vendors have finally begun to add support to generating service and data classes from the WSDL and schemas instead of the code like you are supposed to. As an earlier poster said, web services are not remote procedure calls.
    However, with a document-centric approach, how do you map it to a function call? Just pass the whole document? Alternatively, you can have a mapping from a document structure to a function call. But then you again increase the complexity of your system.

    How is that adding complexity to your system? The WSDL to code generation handles the mapping of messages (identified by the root element in the WSDL) to method representing the service operation, and thanks to data binding the method is receiving the message in object form. So what is so difficult about that? Is it too difficult for you to write a method that knows what objects it receives?

    If you keep your WSDLs and schemas separate from each other and out of the message content, you will find it easier to create services that are interoperable across technologies and reuse common data structures and bindings in messages and throughout the system.

    The WSDL maps message structures to transports, protocols (not just SOAP) and service operations without getting into the business of defining and maintaining data structures and bindings. You can easily make the same service available across different transports and protocols. You can also reuse message structures in different versions of the same service or wherever you need them.

    You can map the components you use to compose your services to message substructures (elements) and make them work automatically in the same way SOAP handlers process the header elements. That allows you to dynamically compose your services from the message contents instead of hard coding their entirety.

    The available SOAP stack may be getting a bit overwhelming, but its all optional as far as SOAP is concerned. So use only what you need.
  13. RPC is dead, long live RPC?[ Go to top ]

    An RPC-based approach will typically give you the same results, in less time, with less overhead and with more performance.
    Nonsense! A document/literal SOAP message has less overhead than RPC. You are no longer carrying structure and type information in your payload, just the data.

    I don't know which RPC technology you are referring to, but with REST-RPC, there is virtually no overhead. Here's an example of a request:
    GET /?_function=GetCart&cart=1563 HTTP/1.1
    Host: test.rest-rpc.org
    Accept: text/xml
    Connection: close

    An example of a response:
    HTTP/1.1 200 OK
    Content-Length: 114
    Content-Type: text/xml
    Connection: Close

    <result>
    <param name="creation">20050923T123507+0100</param>
    <param name="priceAmount">60.5</param>
    <param name="priceUnits">EUR</param>
    <param name="itemCount">4</param>
    </result>

    So where's the overhead?

    Again, I do think that SOAP has a market. So we share some ground. We just don't agree on whether SOAP is a one-size-fits-all solution. I strongly believe there is a strong case for a simple RPC alternative, in the spirit of XML-RPC and REST. Hence REST-RPC.
  14. RPC is dead, long live RPC?[ Go to top ]

    with REST-RPC, there is virtually no overhead. Here's an example of a request:
    GET /?_function=GetCart&amp;cart=1563 HTTP/1.1Host: test.rest-rpc.orgAccept: text/xmlConnection: close
    An example of a response:
    HTTP/1.1 200 OKContent-Length: 114Content-Type: text/xmlConnection: Close<result><param name="creation">20050923T123507+0100</param><param name="priceAmount">60.5</param><param name="priceUnits">EUR</param><param name="itemCount">4</param></result>
    So where's the overhead?
    How is this different from a regular HTML request with arbitrary character data in response?
  15. RPC is dead, long live RPC?[ Go to top ]

    How is this different from a regular HTML request with arbitrary character data in response?

    Here the difference is the definition of the tags to be used and their meaning. HTML is aimed at visual markup (for display to humans), whereas REST-RPC is aimed at system-to-system communication (to be interpreted by systems, primarily).
  16. RPC is dead, long live RPC?[ Go to top ]

    I don't know which RPC technology you are referring to, but with REST-RPC, there is virtually no overhead. Here's an example of a request:
    GET /?_function=GetCart&amp;cart=1563 HTTP/1.1Host: test.rest-rpc.orgAccept: text/xmlConnection: close
    An example of a response:
    HTTP/1.1 200 OKContent-Length: 114Content-Type: text/xmlConnection: Close<result><param name="creation">20050923T123507+0100</param><param name="priceAmount">60.5</param><param name="priceUnits">EUR</param><param name="itemCount">4</param></result>
    So where's the overhead?

    So you've chosen not to type any of your parameters. O.K., but let's compare and ask where is the overhead in SOAP document/literal? To do the same thing in SOAP the only additional tags required are <envelope> and <body> to wrap your message. But your example is really just REST, not RPC though in pure REST I would instead send the message with explicitly named elements (e.g. <creation>) instead of using an attribute and a generic element.

    My reponse was an objection to the whole notion that SOAP document/literal is necessarily more difficult or has excess overhead than various RPC styles. It is not true, but people confuse SOAP with the header stacks you can optionally use with SOAP. Its not an apples to apples.

    So if I wasn't doing SOAP why wouldn't I just use REST XML messages? Why REST-rpc at all? (I do use REST to clients, btw.)
  17. RPC is dead, long live RPC?[ Go to top ]

    why do you consider a documented-oriented interface a necessity?
    I don't consider it necessary, I consider it convenient and less maintenance over the long haul. I'm a big fan of one way to get the data - not one way for this guy (REST) and one way for that guy (SOAP). What happens when the REST stuff fractures? Will you now do a REST++ interface and a REST# interface as well and also a SOAP interface? That's one of the things about SOAP - even though it can be "chatty" at least LOTS and LOTS of folks have accepted it as being the standard.
    Also, consider automatic code generation.
    Auto code generation can be done for SOAP as well as it can be done for RPC. Actually, I do alot of doc/literal wrapped code generation for SOAP messages all the time - today. Actually, by having multiple protocols for Web Service communication it slows down vendors trying to develop good code generation tools (IMHO) and it really hampers interoperability. Why not just standardize on SOAP, get the tools made that really do a good job of dealing with SOAP and be done with it already?
    However, with a document-centric approach, how do you map it to a function call? Just pass the whole document? Alternatively, you can have a mapping from a document structure to a function call. But then you again increase the complexity of your system. And that's exactly what I would want to avoid.
    It's not complexity it's abstraction. It's the same concept with JMS, you don't expose functions over JMS you send messages that represent your data - NOT your function calls. Standardize on the objects used for communicating between services as actual objects that mean something in a larger context than a single method call, don't standardize on what the implementing technology looks like underneath it all (i.e. a method signature).
  18. Whats the point?[ Go to top ]

    Why would you use an REST-RPC when you could just do a REST call returning bespoke XML?

    Need data types? Use XML Schema or custom DTDs.

    Need standardised errors? Use HTTP error codes and / or application specific errors.

    I just can't see the value of this beyond giving XINS a bump in status.
  19. Whats the point?[ Go to top ]

    Why would you use an REST-RPC when you could just do a REST call returning bespoke XML? Need data types? Use XML Schema or custom DTDs.

    Applying plain REST makes sense.

    However, defining an RPC protocol gives additional benefits in terms of interoperability and usability of the definitions. For example for generating documentation on the definitions. Or for generating client- and server-side code.

    Additionally, REST-RPC adds another important feature, which is browser-compatibility. So if you stick to the REST-RPC calling convention, you could generate test forms and call your API directly from your browser. This can be a big win for testing.

    And then there are some issues that need to be resolved if you develop your own custom REST application. How do you handle Unicode characters? And how do you map from resources to functions? How do you support complex values in the input (sets, lists, key-value pairs)? How do you do type validation? If you apply Schemas, then what kind of deployment model do you apply for it? What kind of timestamps do you support? For a typical application, these are questions that need to be answered.

    So why re-invent the wheel instead of considering standardizing on a lightweight RPC protocol? REST-RPC aims to provide an infrastructure within which RPC applications will be easy to define, implement, test, deploy and maintain. At least as far as the RPC protocol can help it.
    Need standardised errors? Use HTTP error codes and / or application specific errors.

    HTTP error codes are nice. But they do map to RPC error codes one to one. For example, if an RPC protocol requires a function name to be specified and the request does not specify it, then is this a 400 Invalid Request or a 404 Not Found? The choice seems to depend on rather philosophical preferences. Also, the 3xx redirection codes may not make any sense in a contained environment where you never want any redirections.

    Secondly, RPC applications may want to include more information in the response about what has actually gone wrong. For example, if the request is considered invalid (HTTP status code 400), the RPC application could indicate what is considered invalid in the request. For example:
    <result errorcode="_InvalidRequest">
    <data>
    <missing-param name="iconID" />
    <missing-param name="tileID" />
    <invalid-value-for-type name="author" type="authorID" />
    </data>
    </result>

    This shows that REST-RPC brings concrete added value.

    Note that if you only have application-specific error codes, it's quite hard to build frameworks with added value. Such as standardized error reporting. This is in fact one of the weaknesses of XML-RPC. That's why REST-RPC (a) standardizes on the way error codes are reported, (b) defines some standard error codes, (c) supports the definition of custom error codes.
  20. REST-RPC an Oxymoran?[ Go to top ]

    Is this approach RESTful? My understanding is that REST is usually contrasted with RPC based approaches. REST-RPC sounds to my ears like 'procedural object-oriented programming', or military intelligence -- a contradiction in terms.

    With RPC the key concept is that of a function, and you based it query parameters to tell it what things to retrieve or do. In REST the key concept is that of a resource, a thing, and there are only 4 verbs. You have an example URL on your site:

    http://test.rest-rpc.org/?_function=GetCart&cart=1563

    This is the antithesis of a RESTful approach. Instead of identifying the function (get cart) and passing a parameter to the function (cart # 1563), a RESTful approach would identify the cart resource itself in the URL:

    http://test.rest-rpc.org/cart/1563

    I don't need to say 'GetCart' because if I want to perform a GET I issue a GET request!

    I just don't get it.

    Steve
  21. REST-RPC an Oxymoran?[ Go to top ]

    Steve,
    Is this approach RESTful? My understanding is that REST is usually contrasted with RPC based approaches.

    No it's not completely RESTful, indeed. While SOAP is document-oriented, REST is resource-oriented and RPC is function-oriented.

    This name was chosen because this RPC approach comes very close to what REST is perceived to be, namely a simple method for implementing services. The most well-known public APIs that are not SOAP-based, such as those from Google and Yahoo, are referred to as REST services while they are in fact just simple HTTP-based RPC services.

    An alternative name would be POX-RPC.

    If the name is confusing, we will consider changing it.
  22. REST-RPC an Oxymoran?[ Go to top ]

    Ernst,

    I was indeed quite confused by this "REST-RPC" title that you gave to this discussion. I'd definitely prefer the "POX-RPC" name which is closer to your original source of inspiration (XML-RPC).

    Also, I don't agree when you say that SOAP is document-oriented and REST resource-oriented. The three main concepts in REST are the resource, its identifier and the representations of this resource. Those representations are actually documents and in any format: HTML, XML, CSS, images, etc.

    Also, I don't see the point in drawing arbitrary lines between different architectural styles. In the end they have much more things in common than differencies. They overlap each others in many ways because they attempt to solve similar problems (distributed computing over Internet).

    For example, you could use the Restlet project as a foundation for your XINS framework. People wanting to run POX-RPC services as well as RESTful applications and even static pages could run just one server to host everything. And the Restlet framework also have a client-side part to support your XINS clients. Let me know if you're interested.
  23. REST-RPC an Oxymoran?[ Go to top ]

    I was indeed quite confused by this "REST-RPC" title that you gave to this discussion. I'd definitely prefer the "POX-RPC" name which is closer to your original source of inspiration (XML-RPC).

    We will consider this as an alternative name. It looks indeed like POX-RPC covers it better.
    Also, I don't see the point in drawing arbitrary lines between different architectural styles. In the end they have much more things in common than differencies. They overlap each others in many ways because they attempt to solve similar problems (distributed computing over Internet).

    True, but the whole point is in the differences, not in the things we all agree on. Otherwise there would be no discussion, would there? :-)

    But I see your point. Indeed we may be trying to draw the lines too strictly.
    For example, you could use the Restlet project as a foundation for your XINS framework. People wanting to run POX-RPC services as well as RESTful applications and even static pages could run just one server to host everything. And the Restlet framework also have a client-side part to support your XINS clients. Let me know if you're interested.

    This is the first time I hear of this Restlet project. Sounds like it's worth investigating whether the combination with XINS makes any sense. I do see quite some overlap, since the XINS server already allows static content, has generic support for different calling conventions (real REST, "POX-RPC", SOAP, XML-RPC, etc.) and it also generates client-side code.

    Since XINS 1.4.0 has just entered the beta stage (all features implemented) we won't have much time for the investigation in the short term, but I'll put it on the TODO list.
  24. Definitional Problem[ Go to top ]

    I see the main issue as a definitional one. Is all that is not WS/SOAP REST? No - not really - REST has to have some key unambiguous concepts which do not necessarily coincide with the complement of SOAP. In other words, not all XML/HTTP or POX (Plain Old XML) is necessarily REST.

    I see the breakdown as threefold:
      1) WS/SOAP - subscribes to standard(s)
      2) Pure/Real REST - conforms to 4 HTTP verbs, etc. - issue is that there is no canonical standard approaching 1)
      3) All else - non-WS/SOAP and non-REST

    Mark Little sums it up succinctly:

    "But, then I reminded the audience that REST in practice is different from REST in theory. The part of REST that is really being widely used is the ability to interact with Web Services using HTTP GETs."

    See link

    -- andre
  25. REST-RPC an Oxymoran?[ Go to top ]

    Is this approach RESTful? My understanding is that REST is usually contrasted with RPC based approaches. REST-RPC sounds to my ears like 'procedural object-oriented programming', or military intelligence -- a contradiction in terms.With RPC the key concept is that of a function, and you based it query parameters to tell it what things to retrieve or do. In REST the key concept is that of a resource, a thing, and there are only 4 verbs. You have an example URL on your site:http://test.rest-rpc.org/?_function=GetCart&cart=1563This is the antithesis of a RESTful approach. Instead of identifying the function (get cart) and passing a parameter to the function (cart # 1563), a RESTful approach would identify the cart resource itself in the URL:http://test.rest-rpc.org/cart/1563I don't need to say 'GetCart' because if I want to perform a GET I issue a GET request! I just don't get it.Steve

    I agree with all you say, but would add that it should be possible to specify the verb as an optional parameter, overriding the HTTP verb used. This would be very useful for developers working in environments where the web servers are locked down to GET & POST only.

    A standardisation of REST along these lines would be very useful IMO. See here for discussion of document-based processing and workflow.

    Kit
  26. What a joke![ Go to top ]

    How thrilling: another amateur RPC specification. This stuff seems to attract only those who deal exclusively with trivial cases.

    When I saw the encoding that this "new" REST-RPC uses, I almost snorted beer up my nose. XML-over-RPC-over-XML, hello.

    If you get serious for a second you begin to wonder about complex types, namespaces, service contracts, WS-* functionality, strong-typing, tooling, etc.

    That overly-simplistic proposals like this get any airtime is an insult to professional developers everywhere.

    Sorry to be abrasive but this is getting silly. Grow up and use WSDL/SOAP, or be left in the dust when hard problems come around. And to those that claim that SOAP is tough, find another job or a decent toolkit.
  27. RFC: REST-RPC[ Go to top ]

    (...) the protocol is simple and powerful.

    Web services are complex because the WS-stack does exist, as a path to open evolution. So how will we handle complexity when it happens into projects, if using rest-rpc, other than with proprietary code ?
    The stack of Web Services technologies is still growing.

    This is good news. The more they implement, the less we code tomorrow, the more we interoperate.
    So browsers can call such services directly.

    I read they can call WS equally, including with ws-* extensions (addressing, ...).

    In 2006, programming ws is pretty straightforward. In php, it's a couple of lines. In java, a couple of clicks in you prefered IDE. I agree that internals are scary, but I guess basic usage is no more difficult than with rpc.
  28. CORBA, WebService, EJB or ...[ Go to top ]

    How about with a single point of entry for remote invocation for a wide number of transports: eg. CORBA, RMI, EJB, JAX-RPC, XML-RPC or other. The client side don't know, what are transport provider he is calling. The invocation is encapsulate behind an abstraction layer.
    Examples are spring (http://www.springframework.org/) or crispy (http://crispy.sourceforge.net/) or in part XINS (especially WebService).
  29. That's all you need to send messages over HTTP. Anything else is just complexification.