Elliotte,
Interoperability between clients and servers at the wire level is
different from consistency between client-side and server-side API
design, especially when several implementations of the same API are
expected. In our case (RESTful Web services API), the common
denominator should be all of HTTP 1.1 and just HTTP 1.1.
I don't think it would be wise to include any kind of object
serialization to/from XML in such API if that is your concern. We
don't want to fall into WS-* interop issues as you correctly point.
> Consider a Representation class, for example. The server sends a
> representation and the client receives it, so it should be appropriate
> for them to use the same class to model it, right? Actually no. The
> client and server have different views of this object. For instance the
> server is probably going to want some sort of pointer back to the
actual
> resource from which the representation is derived while the client
> should not see any such pointer.
Talking about the Restlet's Representation class, it doesn't contain
any reference to the parent Resource, so that is not an issue for us.
We never had an user complaining about this design choice.
> Furthermore, the client needs a way to get a byte array or
InputStream for the message body in the Representation. The server
needs a way to set the byte array or get an
> OutputStream for the message body. If you try to get away with one
> Representation class, then each side will have methods it doesn't need.
In our case, we designed the Representation class like a Content (or
like an HTTP entity if you prefer) that can be either written to an
OutputStream (or to an NIO WritableByteChannel) or read by getting an
InputStream (or an NIO ReadableByteChannel). We have several abstract
implementations that can let you automatically convert from one IO
mode to another. Have a look at this hierarchy diagram:
http://www.restlet.org/tutorial#conclusion
Check also the Javadocs of the org.restlet.resource package:
http://www.restlet.org/docs/api/org/restlet/resource/package-summary.html
Best regards,
Jerome