bugfox blog

I know I’ve been dissing SOAP and WS-* quite a bit lately, but I can’t let this pass unnoticed.

If Richard Monson-Haefel of all people can’t easily use one of the leading toolkits to create a simple client for some of the most popular web services, how likely is it that the average programmer will be able to do a decent job? Keep in mind that the main selling point of these frameworks is that they are supposed to make it simple to use web services.

I think it’s time for the tool vendors to admit that this whole approach is a mistake. The idea of creating distributed applications by making RPC calls across the network, using code generators to hide all the details of network communications, has been around for over ten years. It sounds appealing at first, but we have had time to see how well it works in practice:

• Fragile, hard-to-maintain applications.
• That generally don’t scale well.
• And usually won’t interoperate with other vendor’s frameworks.

Tim Bray responds to Elliotte Rusty Harold’s negative comments in this post:

Hey Elliotte, I guess making friends and influencing people is for losers, right? The proof of the pudding, obviously, is in the eating, but the fact that this discussion is happening has to be a good thing.

Marc Hadley responds with some clarifications of what they are trying to do, and some sample code to show what they have in mind.

HTTP is the target of this API, we went back and forth a bit on the name and in the end decided to use RESTful in there to highlight that it will focus on RESTful use of HTTP. It doesn’t mean we plan to develop an abstract REST API with a binding to HTTP.

The sample doesn’t look to bad; at least it looks better than the existing APIs. However I see some issues that I hope will be addressed:

• The sample seems to assume that the message contents will be passed as strings. This would be fine for short messages but would probably be very inefficient for long messages.
• MIME attachements would also need to be supported.

ERH asks

why is this being proposed for Java Standard Edition at all? The proposal seems to depend on JAX-WS and the Java Servlet API, neither of which is included in the Java 6 Standard Edition. Will these packages have to be added to Java SE just to support this?

That’s a good point. Obviously there needs to be two packages:

1. A client-side API that belongs in Java SE
2. A server-side API that should be part of Jave EE or installable separately

Does that require two separate JSRs?

Elliotte Rusty Harolde wants everyone to submit comments on the proposed Java API for RESTful Web Services asking them to drop the whole idea:

…there are some companies (Sun being one of them) that can’t imagine regular, ordinary developers building systems without using some ultra-complex framework they’ve designed. The idea that people might just want to send plain old XML over plain old HTTP is inconceivable to them. There has to be some big framework for serializing objects and abstracting databases and faking method calls and guaranteeing message delivery and a dozen other things people either can already do perfectly well with HTTP and XML or don’t actually need to do at all.

…The problem is not HTTP or requiring developers to understand it. The problem is that Sun’s server-side HTTP API blows chunks…

I agree that this sounds misguided. If you provide SOAP-style wrappers around REST to hide the fact that you are dealing with HTTP, then is just isn’t REST anymore, and you will probably end up with all of the problems of SOAP and WS-*.

SEOmoz | Web Developers: 13 Command Line Tricks You Might Not Know

Via Cafe con Leche.

Kurt Cagle argues (and I tend to agree) that the current fashion for AJAX is likely to result in a lot of nasty, unmaintainable code that probably will be full of security holes as well. He thinks that everyone should be thinking in terms of XForms instead: Why XForms Matter, Revisited - O’Reilly XML Blog

But the only implementation that he mentions is the experimental one for FireFox. Clearly we will need more than that. See his comments for some other alternatives.

To the horror of many developers Google is abandoning its SOAP Search API.

Dave Megginson comments. Is this the beginning of the end for mashups and all the “Web 2.0″ excitement? Or just the end of SOAP? (Steve Loughran).

via Pete Lacey.

UPDATE: More thoughts from O’Reilly Radar.

Presumably for the benefit of those who find the RFC hard to follow, Mark Pilgrim translates the HTTP response codes into toddler-speak: REST for toddlers.

The REST vs WS wars continue. Pete Lacey has an insightful post on RESTful Security, and a further clarification: Clarity Around Security.

More on SOA vs REST, XSD vs Relax-NG, etc.

Pete Lacey says They can’t hear you. I think this is a realistic assessment of the current reality facing corporate developers.

It seems that all the great minds of the XML world are declaring that W3C XML Schemas (XSD) are dead, and everyone is going to switch to Relax-NG. Cf. Elliotte Rusty Harold and Tim Bray. However I think a lot of us who live in the corporate world are going to be using XSD for a long time.
(more…)