ramen

PUT is used when you know the URL you are creating and you can send a whole resource. This, by convention, has been interpreted by many to mean updates, but not everyone agrees. The Basecamp API for instance uses "PUT /todo_items/#{id}/complete.xml" to mark a TODO item as complete. Is this creating a new "complete" resource, or updating a "todo_item" resource? Either way, when trying to make an API fit the REST style, one must fit everything into the standard verb / filesystem-like mold. With plain-old RPC, you name your methods whatever makes sense to you, using your time-earned experience in designing regular libraries, and you don't waste a moment on these nitpicky decisions.

The lack of consistent client support for PUT and DELETE further complicates this issue. As you say, you can abstract away the emulation of these verbs, but what library are you speaking of? A single-purpose solution to wrapping a particular REST interface? Or a one-size-fits-all REST wrapper that works with any server? I'm not sure the latter is possible, since there are once again multiple ways to do this - "?_method=PUT"? X-HTTP-Method-Override? Or something else entirely... it's not standardized, and REST isn't a spec, it's just a style, so everyone does it their own way. All of this so that we can write "PUT" at the beginning of the HTTP request line instead of further down or to the right? What is the actual benefit to all of this extra work?

The biggest issue with parameter-passing style is the lack of a standard way to pass complex data structures. It's as if every function took only a single argument, a string, and had to run a regex on it, splitting the results on delimiters, each in its own special way. If a regular software library were written this way, it would be appalling. At least PHP gave it a shot, with its arr[]1=&arr[]=2... syntax, but nobody's going to standardize on that, since query strings are unfashionable now, and nobody likes PHP anymore. I honestly think we should go back to query strings and stop embedding data in URLs because at least you get named parameters. And if you subscribe to the HATEOAS camp, they're more RESTful since we already have one standardized, well-documented way to provide clients all they need to build them (HTML forms).

You're right, just because people don't use something consistently doesn't mean you should throw the whole thing out. I didn't mean to imply that. What I stand by, however, is that HTTP status codes were not designed for APIs, and that as a result they are guaranteed to be used inconsistently when used for the purpose of designing APIs. At least with all-custom error codes there's no expectation that everyone will interpret the HTTP standard correctly as applied to a problem it was never intended to solve.

HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?), several ways to specify parameters (URL path fragments, query strings, headers, or POST data?), and a set of standard errors that you do not control and which are not used consistently. I like how XML-RPC ignores all of that, because there are too many ways to do the same thing.

Indeed. The parameter-passing mechanism is something XML-RPC decides for you, rather than leaving the task of string concatenation (or XML message-building) to you. One might even call this "opinionated".

So 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.

The difference is that your example uses a URL as input and outputs a JSON blob. The URLs still need to be constructed somehow and the output needs to be parsed if you want to do anything useful with this service. To compare apples-to-apples:

    >>> import urllib, simplejson
    >>> person_id = 1
    >>> person = simplejson.loads(urllib.urlopen('http://my-fake-service.com/people/%d.json' % person_id).read())

Now you have a data structure you can work with. But you've just traded a nice parameter-passing syntax for string building, and you're parsing JSON manually. Of course, you could wrap all of this with an API, and you probably should, but XML-RPC does a lot of this wrapping for you.

To 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.

Caching has been the main reason I have chosen REST over XML-RPC in certain instances - the ability to use existing web proxy and caching solutions to cache an API is certainly convenient. However, I completely agree about your last sentence here. Cache invalidation is tricky, since there isn't a standard HTTP method to tell a web cache to forget something it has cached. Also, client-side caching at a higher level using something like memcached has worked demonstrably better for me in many instances, and it offers more fine-tuned control over lifetime and expiration.

There is a de-facto standard for that: system.listMethods to list supported methods, system.methodSignature to get the parameter and return types for a method, and system.methodHelp to get its documentation. It's not an ideal solution, since method signatures are shallow and not every server implements these methods the same way (or at all), but they are enough to do basic code generation for statically-typed languages. Here's an example of that for OCaml: http://code.google.com/p/xmlrpc-light/source/browse/trunk/ex...

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/

Yay! Dropbox is a winner in my book.

I know you all know this, but I feel like it bears mentioning that nobody is forcing you to use list comprehensions whether map/filter stay in Python's built-ins or not. They can be defined in around 3-4 lines of code each. Lisp aficionados, already accustomed to the bottom-up style of programming, ought to have no problem writing functions like these as necessary.

So this is a feature? I thought it was just broken in Linux.

For-loops like "for (i=0;i<myLinkCollection.length;i++)" should always be written like "for (var i=..."), unless there's an explicit "var i;" declaration somewhere. Otherwise, this creates a global variable "i", which can lead to some very confusing bugs if another function is called that also references the global "i".

Google Groups used to be a great service when they first took over Deja News, but things have been gradually deteriorating ever since.

They used to be read-only; now, they allow anyone with a fake account to post. They are a huge source of Usenet spam. I have been kill-filing posts from Google Groups for about a year. It's not a pleasant thing to do, since there still are quite a few people who I like to read but only see quoted in replies now because they use Google Groups.

Whenever someone posts the same article 10 times in a row on a Usenet newsgroup, I always look at the mail header, and every single time it is from Google Groups. I don't know what is wrong, but there must be some user interface bug that causes people to resubmit their post. Maybe they don't realize that Usenet has a lag between posting and seeing your post. Maybe there's something wrong with the submit button. I don't know, but I've been seeing this phenomenon for a few years now.

Initially, Google Groups made a clear distinction between Usenet newsgroups and Google's own groups, but they've been blurring the two more and more over the years. The result is that a lot of people don't even know they're posting to Usenet, and are unaware of the different etiquette and social customs there (real names, top posting, etc.). Lately they've started including third-party forums as well, so now it's basically a free-for-all, and there is no way to just search Usenet anymore. You have a choice between "Google Groups" and "all groups", where the latter includes Google Groups, Usenet, and random bulletin boards on the web.

If Google isn't interested in supporting Usenet with a decent archive anymore (and I can understand their reluctance, since I'm sure there's little to no money in it) I wish they would pass the responsibility to someone else and get out of the way, because at this point I wish Deja News was still around - I'd have no need for Google Groups anymore.

And I know everyone loves to bash on Usenet, about how it's obsolete and dead, but I have to say that at least when it comes to programming language newsgroups, it's still hopping. I follow about a dozen programming newsgroups, and I can't keep up. About once a week I have to "mark all as read". As long as it still causes information overload, I don't think it can be fairly declared extinct.

zip is matrix transposition in disguise.

ramen

But, I thought, worse was better? I'm so confused... =)

Beware of hyperbole.

My point is that PHP's lack of namespace hierarchy is just like C. In fact, most of PHP's libraries are very close to the underlying C libraries. The lack of apparent organization is mainly due to the fact that PHP pulls all these different, independently-written libraries together. If you were writing C, it would look about the same, except that you'd have to go out and find all these libraries and put them together yourself.

If you think that's bad, you should try C sometime.

I often find myself defending PHP. It seems to be very unpopular lately, at least by some very vocal individuals on the web. I like PHP, and here's why:

It runs everywhere, has lots of libraries, and most of my friends know it.

That, for me, is huge. It's enough for me to forgive, tolerate, and even enjoy programming in the language.

Anyway, here's what I don't like:

The lack of a decent module system.

The lack of closures.

The weird reference semantics of objects in PHP4. PHP5 is way better in this regard, but now I have to worry about whether my code will still run on PHP4, and whether or not I will need it to.

The clumsy templating syntax. Short tags help, but I'm supposed to feel guilty if I use them.

The need to use unreliable third-party software to get bytecode precompilation, causing me to worry about the performance costs of modularity. (!)

Magic quotes. And the fact that I may need to undo them depending on the whims of system administrators.

Arrays. I wish dictionaries and lists were separate concepts like they are in Python and many other languages I want to interoperate with.

The name. I hate when I have to explain what PHP stands for. I feel like enough of a geek as it is.

He should come with a towel.