Search the web
Sign In
New User? Sign Up
rest-discuss · REST Discussion Mailing List
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Show off your group to the world. Share a photo of your group with us.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
Another potential problem with the 311 proposal   Message List  
Reply | Forward Message #7876 of 14247 |
Re: Another potential problem with the 311 proposal


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





Thu Feb 15, 2007 3:13 pm

jerome.louvel
Offline Offline
Send Email Send Email

Forward
Message #7876 of 14247 |
Expand Messages Author Sort by Date

There's an assumption so far in this thread that the 311 proposal is purely a server side technology. However, I can find nothing in the JSR to explicitly...
Elliotte Harold
elharo@...
Send Email
Feb 15, 2007
12:25 pm

Hi Elliotte, In my mind this JSR is only aimed at server-side applications. However, if you take the Restlet API, it is both a server-side and client-side API...
Jérôme Louvel
jerome.louvel
Offline Send Email
Feb 15, 2007
2:09 pm

... One goal of both WS-* and REST is that clients written in a multitude of languages on a multitude of platforms will be able to talk to each other ...
Elliotte Harold
elharo@...
Send Email
Feb 15, 2007
2:47 pm

Elliotte, Interoperability between clients and servers at the wire level is different from consistency between client-side and server-side API design,...
Jérôme Louvel
jerome.louvel
Offline Send Email
Feb 15, 2007
3:16 pm

... Multiple implementations of the same API is rarely necessary and has resulted in overly complex designs throughout the Java class library. The big smell is...
Elliotte Harold
elharo@...
Send Email
Feb 15, 2007
3:50 pm

... I haven't had as much time to spend getting familiar with RESTlet as I would like, but that's partially a function of its complexity, and that's partially...
Elliotte Harold
elharo@...
Send Email
Feb 15, 2007
4:06 pm

... I'm very often writing programs that handle both sides of that equation at the same time. Usually my concerns about the app as a client and as a server are...
Jon Hanna
hack_poet
Offline Send Email
Feb 15, 2007
4:12 pm

Elliotte, ... In just two lines you can output the content of a Web page to the console. I don't think it is that complex compared to other APIs I've seen: ...
Jérôme Louvel
jerome.louvel
Offline Send Email
Feb 15, 2007
4:41 pm

... I agree. Moreover, I also think you generally have different design goals with client and server APIs. For example performance is normally a lot more...
Mark Baker
gonga_thrash
Offline Send Email
Feb 15, 2007
3:19 pm

Hi Mark, ... I understand your point of view, but we also have to take into account applications that need high performance for clients too. Implementating...
Jérôme Louvel
jerome.louvel
Offline Send Email
Feb 15, 2007
3:49 pm

... Then they can use an ... Seriously? I already gave an example of why they might need to be different; because the requirements and/or design goals may be ...
Mark Baker
gonga_thrash
Offline Send Email
Feb 15, 2007
4:03 pm

... Oops. Meant to say "They can use a high performance client API then". Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca ...
Mark Baker
gonga_thrash
Offline Send Email
Feb 15, 2007
4:10 pm

Mark, ... Sorry, I missed your example. Could you point it to me? ... In our case, that was a goal added soon in the design process when we realized we were...
Jérôme Louvel
jerome.louvel
Offline Send Email
Feb 15, 2007
5:22 pm

... The spec defines what it is. The API defines what you can do with it. The different ends of the connection want to do different things with the medium of...
Elliotte Harold
elharo@...
Send Email
Feb 15, 2007
4:25 pm

At Thu, 15 Feb 2007 11:25:05 -0500, ... This distinction between client & server APIs has hurt the REST style, in my opinion. An example: most *client* APIs...
Erik Hetzner
e_hetzner
Offline Send Email
Feb 15, 2007
6:21 pm

... I don't see anything in the concept of either "client API" or "server API" that imlies "Please suck at the following depending on whether you are a client...
Jon Hanna
hack_poet
Offline Send Email
Feb 15, 2007
7:07 pm

At Thu, 15 Feb 2007 19:05:44 +0000, ... I was a bit unclear. What I’m suggesting is that client & server APIs have different ways of getting at a message’s...
Erik Hetzner
e_hetzner
Offline Send Email
Feb 15, 2007
7:32 pm

... There is not one API or library to rule them all, nor should their be, though standardization often attempts to create such a beast. Different use cases...
Elliotte Harold
elharo@...
Send Email
Feb 15, 2007
4:31 pm

Jerome, There's a huge difference between a protocol specification such as HTTP and an API specification for a protocol. HTTP is the same for both client and ...
Dave Orchard
dorchard100
Offline Send Email
Feb 16, 2007
2:13 am

Hi Dave, I think we agree. HTTP clients and servers do received the same Data but they use it in different ways. The Restlet API reuses the same classes to...
Jérôme Louvel
jerome.louvel
Offline Send Email
Feb 16, 2007
8:58 am

... At the same time, on the assumption that servers often talk to remote systems, having the ability to chain stuff across the connection is kind of useful....
Steve Loughran
steve_loughran
Offline Send Email
Feb 16, 2007
9:50 am

For those people who are not subscribed to the apache jcp-open mailing list, in which apache participation in/votes on JCP proposals are discussed, here is the...
Steve Loughran
steve_loughran
Offline Send Email
Feb 17, 2007
9:35 pm

... I am of the opinion that it can be useful to share the same abstraction, though it has to be fairly finely tuned and you may still have some tweaks on one...
Benjamin Carlyle
fuzzybsc
Offline Send Email
Feb 18, 2007
9:18 pm
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help