REST is a good set of design suggestions for designing web services, but, like anything else, don't get too caught up in adhering to the philosophy. Use the techniques that will work best for the problem you're trying to solve.

SOAP should be avoided at all costs. It has no redeeming qualities whatsoever and was probably responsible for the Teletubbies. In any case, REST applications tend to be designed more around a "give me this chunk of information" and "put this chunk of information there" concept, whereas SOAP is a bad attempt at doing RPC over XML over HTTP, which probably isn't what you want.

As for good design ideas, look at what the AJAX people are doing. The really rich AJAX applications are Javascript applications that consume a Web API.

Right now, REST along with JSON are the predominant players in the opensource Web Services stack. To that end, RESTful Web Services is a good book to start with. That being said, as friedo pointed out, REST is not the be all, end all of Web Services.

Here are some of the pro's of of using REST/JSON:

• integrates well with AJAX
• JSON more perlish than XML
• CRUD maps nicely into the HTTP verbs

And here are some of the cons:

• badly designed services can put a huge load on your server (AJAX gone wild).
• Error handling hard to map well into HTTP response codes
• PUT and DELETE not supported by all servers
• POST/PUT tends to be in flux as to which is a CREATE and which is UPDATE (for me, POST is an UPDATE and PUT is a CREATE, but apparently I'm in the minority).

That all being said, REST/JSON/AJAX has been a refreshing approach to building webapps for me.

Thanks all for the replies.

About PUT and DELETE server support, we're using Apache2. Do you know if that's on the bad list?

Assuming I fashion a system using REST/JSON/AJAX, how big of a problem is it if consumers of the API say they would prefer XML? There are at least two solutions:

1) Give them XML, even though the core of the system uses JSON - how easy is this in a R/J/A solution, can it be just like adding another view in an MVC application?

2) Convince them that JSON is just fine - depends on how good the Java support for dealing with JSON is, and on whether the manager is thick-skulled. If Java support for JSON is not so great, then I have a political problem that may override the technology decision. According to the JSON web site, most languages have great support for JSON, but is this just JSON marketing, or is it true? Personally, I'm already sold on JSON, but I'm wondering what you (anybody) have heard about the difficulty of selling the Java people on it.

- Apache 2.0 will be fine.

- Supporting different encoding methods is really easy - just check the client's Accept: header (e.g. text/xml or text/json), or a GET/POST parameter (/path/to/app?format=json), or whatever, and pass your data structure to the appropriate module for serialisation (e.g. JSON or XML::Simple) before returning it to the client.

- There's java code on json.org that will do it, otherwise XML::Simple is easy to use on the Perl side.