4 ms·
I like how XML-RPC support is built into Python. If a server supports XML-RPC, I can get an instant command-line interface that feels like using an ordinary lib
by ramen 17y ago
I like how XML-RPC support is built into Python. If a server supports XML-RPC, I can get an instant command-line interface that feels like using an ordinary library. The data structures that XML-RPC supports are mostly the same as JSON: arrays, hashes, integers, floats, and strings. There are also date/time values, which are automatically deserialized as Python datetime objects, and binary values which are transparently base64-encoded. Being able to use native types is a plus over dealing with XML trees. The lack of object types, in contrast with SOAP, is a feature in my opinion, since it keeps the interface portable across many languages.
XML-RPC uses XML and HTTP, but it hides both from the programmer. I think it is a mistake to criticize XML-RPC for not integrating deeply with HTTP, because HTTP is not really the point of XML-RPC. It's just an implementation detail. It happens that HTTP and XML libraries are everywhere, so XML-RPC lets you tunnel a simple RPC protocol through an infrastructure that is common across many programming languages.
Every REST interface I have tried to integrate with uses HTTP error codes differently, treats the GET/POST/PUT/DELETE commands in its own peculiar way, and has unique requirements for authentication. I am not at all sure that deep HTTP integration is appropriate for APIs. Regardless of the protocol (or "architectural style", if you insist), documentation of data structures, calling conventions, and error codes is essential, and just saying "we use HTTP" is insufficient to communicate these details.
Disclaimer: I wrote the xmlrpc-light library for OCaml. http://code.google.com/p/xmlrpc-light/ http://code.google.com/p/xmlrpc-light/
- generalk 17y agoEvery REST interface I have tried to integrate with uses HTTP error codes differently, treats the GET/POST/PUT/DELETE commands in its own peculiar way, and has unique requirements for authentication. I can't defend systems that (for example) misuse HTTP status codes or ignore HTTP authentication, but this puts it at the same level as XML-RPC, which re-invents error codes, methods, and authentication every time. documentation of data structures, calling conventions, and error codes is essential, and just saying "we use HTTP" is insufficient to communicate these details. I absolutely agree. Documentation is essential for a web service, regardless of how you provide that service.
- ramen 17y agoTo say that some systems "misuse" HTTP status codes implies that there is a correct way to use them. What is the correct way to use HTTP status codes for an API? They weren't even designed for APIs. Where is this specified? Since REST is just a style, not a standard, correct use of status codes is undefined. As a result, everyone uses them differently. For example, what is the correct status code to send when a new resource has been created? XML-RPC does not try to force an existing set of error codes on you. You start with a blank slate. This means you do have to come up with a plan for how you are going to use error codes, but the same is true of REST; the only difference is that you don't have to fit your error model to an existing set of codes designed not for APIs but for serving documents to a web browser.
- generalk 17y agoFor example, what is the correct status code to send when a new resource has been created? From http://en.wikipedia.org/wiki/List_of_HTTP_status_codes http://en.wikipedia.org/wiki/List_of_HTTP_status_codes 201 Created The request has been fulfilled and resulted in a new resource being created. This isn't to say you shouldn't document how your service responds to requests, just that there are response codes you can use that are widely understood. If you want you can respond to everything with 200 OK and require clients to parse responses to understand how your service handled a request, but again this is the same thing XML-RPC gives you.
- ramen 17y agoSo then, sending a 302 redirect in this case would be incorrect? That is how most web forms operate, and the web is RESTful by definition.
- regularfry 17y agoThe web is not, in general, RESTful. State-changes on GET are common, for instance. Client state is regularly held in server-side sessions. PUT and DELETE are essentially unsupported.