Sun proposes to apply Web service standardization principles to REST
- View SourceIt had to happen sooner or later. The big boys are waking up and
discovering REST, and naturally they want to protect all us little
developers from worrying our pretty little heads about nasty things like
HTTP and XML by creating easy-to-use REST frameworks:
JSR-311 Java API for RESTful Web Services
Remember, these are the same jokers who gave us servlets and the
URLConnection class as well as gems like JAX-RPC and JAX-WS. They still
seem to believe that these are actually good specs, and they are
proposing to tunnel REST services through JAX-WS (Java API for XML Web
They also seem to believe that "building RESTful Web services using the
Java Platform is significantly more complex than building SOAP-based
services". I don't know that this is false, but if it's true it's only
because Sun's HTTP API were designed by architecture astronauts who
didn't actually understand HTTP. This proposal does not seem to be
addressing the need for a decent HTTP API on either the client or server
side that actually follows RESTful principles instead of fighting
To give you an idea of the background we're dealing with here, one of
the two people who wrote the proposal "represents Sun on the W3C XML
Protocol and W3C WS-Addressing working groups where he is co-editor of
the SOAP 1.2 and WS-Addressing 1.0 specifications. Marc was
co-specification lead for JAX-WS 2.0 (the Java API for Web Services)
developed at the JCP and has also served as Sun's technical lead and
alternate board member at the Web Services Interoperability Organization
The other submitter seems to be a primary instigator of the Fast Infoset
effort to hide XML in binary goop.
This is like asking Karl Rove and Dick Cheney to write the Democratic
Do we really want to trust these folks to define the official Java spec
for REST? Please read the JSR, and send comments to jsr-311-comments@...
I hope we can derail this completely, but we probably can't. If not, are
there any JSR members here who might join the working group and bring
some sanity and actual REST experience to the development of the
eventual specification? If we can't stop it, maybe we can at least limit
Elliotte Rusty Harold elharo@...
Java I/O 2nd Edition Just Published!
- View SourceThanks for this. It's a fantastic list!
Benjamin Carlyle <benjamincarlyle@...> writes:
> * Every resource should implement as many of the architecture'sSurely this doesn't need to be tested? An application is not
> interaction patterns as makes sense. eg GET, PUT, POST, DELETE,
non-RESTfull if it doesn't implement a method that we may think it
should. That is subjective.
> * Content types shouldAll of these seem testable to me.
> ** Be free from verbs (except for code-on-demand), representing pure
> ** Encode similar data schemas into the same document type
> ** Be standard wherever possible
> ** Include standard documents as sub-documents wherever appropriate
> ** Extend standard document types through subclassing when variation is
> ** Invent new document types when nothing out there is a good fit
> Evolvability:Most of these look like client side things. It has just occured to me
> * Components should ignore features of a document they do not understand
> * Components should avoid wildcard matches in parsing that might lead
> them to interpret a feature they do not understand as if it were one
> they do understand
> * Components should not alter their processing depending on a version
> number found in a document
> * If incompatible changes occur to a document type, it should normally
> be given a new document type identifier
> * Components should continue to support legacy features and interface
> until such time as it is known that they are no longer in use
that automated client testing looks very difficult.
> Horizontal scalability:I think this boils down to a question of not doing cookies or URL
> * When a server does stores state due to client requests, that state is
> ** Hidden from view, or
> ** Made visible as a resource that can be further retrieved and
> * Server-side state storage should be avoided when no money is changing
> hands to support this storage. This can be said for sessions, pub/sub,
> and other times when the server stores state either temporarily or
> perminently. Paying for bandwidth almost involves funny money, but
> storage can really cost you. It hurts horizontal scalability, increases
> complexity, and generally makes life hard. That said, most services need
> to store some state. Just don't to any more than you have to.
http://www.tapsellferrier.co.uk for all your tapsell ferrier needs