

Dare left something out (and it's important) - bootload
http://www.scripting.com/stories/2008/08/17/dareLeftSomethingOutAndIts.html

======
natrius
"What's missing in REST, btw, is a standard method of serializing structs,
lists and scalar types."

What benefit would this provide? I assume he's talking about this:

"We're all writing code, again and again, every time we support a new
interface that could be written once and then baked into the kernels of our
languages, and then our operating systems."

But I've never had to write new code just to parse the data from a REST API.
You can usually request JSON, and there are plenty of libraries out there for
that already. No new code required.

~~~
jonknee
I think his problem is that he programs in Frontier and he hasn't built any
support for JSON.

Library support is a rough spot when you write your own programming language,
develop in it exclusively, and happen to be one of the only people in the
world developing in it. He created his own XML spec for XML-RPC and wants
everyone to use that instead of JSON.

------
calambrac
The nicest thing that I can say about XML-RPC is that I almost forgot I was
using it on one of my projects. That never happens with soap or rest - with
the former, you're always running into compatibility issues, and with the
latter, you're always thinking about how to do things restfully.

------
neilk
HTTP allows you to specify the return format right in the headers of the
response, so that's a clue that a REST ought not to standardize it.

About 95% of the services I use (or write) just send the equivalent of key-
value pairs back to the user. JSON is the best choice here. However, for other
services, the best choice is to send back HTML fragments, XML, executable
Javascript, or even image and graphics formats.

The one thing I would like to see standardized is error handling. Too many
service throw back 200 OK and then, in some custom way in the body of the
response, tell you there was an error. This is like snatching defeat from the
jaws of victory.

However, neither is it really obvious how to return the right HTTP error
status. If someone asks your web service for a map centered at 2000 longitude,
-1000 latitude, what do you say? 404, no such map found? or do you say 409
Conflict, even though that was really designed for PUT mid-air collisions?
There ought to be statuses that more clearly map to common REST service
problems, like "request parameter out of bounds". A common return format to
represent such errors would be great, too.

------
andrewf
If you're building a web service for public consumption, you want random,
interested developers to pick it up easily.

SOAP has a clear advantage over XML-RPC here: blub programmers have probably
heard of it, and it will be supported out of the box in their language and
IDE.

------
cousin_it
> What's missing in REST, btw, is a standard method of serializing structs,
> lists and scalar types.

Just use JSON. Apart from being more compact, readable and parseable, it has
the added bonus of being a data format, not a method-call-on-the-wire format.

