Hi Daniel,
Thanks for the interesting email. I will try and split my reply up into
separate emails.
I have been investigating a client-side API in Jersey based on the
uniform interface constraint and sharing some ease of use concepts and
classes with the server-side API. I already saw and replied to your
comment on my blog entry related to this :-)
My position is that if there is a RESTful client-side API that
sufficiently encapsulates the uniform interface constraint, can be the
"driver of the engine of application-state", and is easy to use then
there is less need to rely statically on specific server-side artifacts
like WSDL [*] or even WADL (my view is WADL should be processed
dynamically and utilized with caching for performance enhancements).
IMHO asking the developer to use the Apache HTTP Client API for RESTful
services is a bit like asking the developer to use the JAX-WS Provider
API for WS-* services. But, i don't think it has to be that way :-)
(note that i think the Apache HTTP Client is rather good base to build a
higher-level general API because it comes with a lot of useful
functionality).
That is the general rational behind the client API i have been working
on. It has worked very well for unit testing, i can rapidly create a
simple server and unit test all in one class. Some other developers have
used it in a larger context and are happy with it, much better that
HttpURLConnection! But i admit that it has not yet been used in real
anger by many developers to see if it really archives it's goals. I also
was looking at how it could be used to interface with
Facebook/Flickr/AtomPub etc and it looks like it would work out
reasonably well with an appropriate auth layer (which is currently missing).
Paul.
[*] A complete machine processable description of the RESTful service
that the client relies on is really antithetical to the REST style. More
in tune with the style is a bootstrap URI and GETing some representation
from that URI to inform the client what links it may traverse to put the
application in different states, and so on. i.e. the descriptions tend
to be much smaller in scope (e.g. HTML forms) to do just enough work to
move to other states.
P.S. I also think the generation of artifacts from XSD is an orthogonal
issue to that of the network interface.
Daniel Manzke wrote:
> Hi all,
>
> first I want to introduce myself. My name is Daniel Manzke and I'm a member
> of the "Java User Group - Berlin Brandenburg". I'm working for a german
> company with headquarter in berlin and I'm really interested in all things
> about web services, integration and interoperability.
> The next thing I want to do is a BIG thanks to Stefan Tilkov for his nice
> presentation. I know jersey since 0.2 so there not so many new stuff for me,
> but some really nice conversations and questions. (I know Stefan will smile
> now ;))
>
> The last thing is, I want to tell you some open points which we could not
> solve. Because I'm developing with jax-ws I had some other views/meanings
> about web services than Stefan. One of the big points was the missing
> "client api". I have to say, that I really love the simple way to develop
> REST-Services, but there is really a lack of a client api. Stefan told us to
> use "Apache HTTP Client", but that's not really a solution. He told us that
> there are some kind of client apis and I'm very interested in them. For
> research or developing as a project. Like a jax-ws common project I have.
> The problem I forgot the name of the guy who had this. Stefan can you help?
> Another point was the missing "code generation feature". With a wsdl you
> could generate your missing classes. I know that there's something called
> WADL, but didn't had a look at this yet. The problem is that for
> "enterprise" usage I need some kind of interfaces. I know that HTTP is the
> "interface" because of the standardized methods, but I have a lack of
> existing resources which this application would have.
> An idea is, that there's a description file which points out all "ways"
> (ressources) and every ressource is described through an XSD. And if I have
> a "client api" all things would be complete and I could generate an api for
> calling the rest service.
>
> The last ones are:
> There was an idea for webdav support. Due my work with the JCR /
> JSR170+JSR283 I asked how to solve some kind of recursive structures.
> Because with the JCR you can create some kind of a tree and it's hard to
> solve this with rest. Stefan told us of some spacers like ** or so on. I
> will looking forward.
> A very good choice for using the JCR api is webdav, because of the ability
> to handle the repository like a filesystem. Due my lack of knowledge of the
> webdav protocol an simple example would be very nice and I thing a big
> "marketing point" for the restful services. Stefan was some kind of
> interested in that, but I had no time after the presentation to fix this
> idea.
>
>
> So enough spam.
>
> Again, a BIG thank you for the presentation and a BIG thank you for this
> nice API.
>
>
> Greets,
> Daniel
>
> P.S: I will help where I can. If you need my "man power" just write me a
> mail.
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109