On 4/13/07, Stefan Tilkov <stefan.tilkov_at_innoq.com> wrote:
>
> The JSR text could be misread to mean "independent of underlying
> technology (HTTP, WS-*, ...) which I definitely hope nobody here wants.
I thought it meant independent of underlying deployment infrastructure (i.e.
servlet, restlet, JAX-WS containers...). Marc/Paul can you shed some light?
> If the goal was to use a traditional style of programming using
> > classes,
> > then we could just require people to:
> > - have all resources extend a base Resource class
> > - have all representations extend a base Representation class
> >
>
> I don't see this as a conflict. Why can't the API use a "traditional
> model" (I didn't even know OO had become traditional yet) and use
> annotations wherever they make things easier?
Sounds sensible to me. Im also not clear on what the difference is between
mapping an object and mapping a graph of objects (are we talking about
cascading mapping semantics a la JPA?).
"The goal of this JSR is to provide an easy to use, declarative style
> of programming using annotations for developers to write REST ful Web
> Services and also enable low level access in cases where needed by
> the application."
>
> My understanding was that this means that access to every "low-level"
> feature is possible in a standardized way.
Yes, but I read that as being in the exceptional case (i.e. where the
declarative, high-level api can't cut it).
> I think that our main concern should be: how can we express the
> > mapping from
> > POJOs to RESTful Web services in the most compelling and in less
> > intrusive
> > ways, while supporting the important high-level Web/HTTP features
> > found in
> > RESTful applications (caching, stateless, identification by URIs,
> > uniform
> > interface, content negotiation, etc.).
> >
>
> Just as a matter of personal opinion, I would be very disappointed if
> this was all JSR 311 achieves. I don't want to see POJOs mapped to
> RESTful Web services; I want to see a good and standardized
> programming model for building RESTful HTTP applications in Java.
> Easy things should be easy and hard things possible.
I am curious what you mean by "building RESTful HTTP applications in Java."
RTF has already said something to the effect that he doesnt believe in such
a thing as a REST application (i.e. built on a "REST" API). I agree in that
I dont believe it's a programming model (like MVC or something).
I ask this mainly because some of the comments on the Yahoo REST mailing
list seemed to push for using jsr311 to build *better* HTTP support in java
(ostensibly to supercede servlet, URLConnection et al). I am not sure if you
were one of those commentors, Stefan.
This would be a diametrically opposed goal to building a high-level
abstraction for web services that use POJOs (I hesitate to say in the
"restful" style--but stateless, transparently layered, cacheable, uniformly
locateable, you get the picture...), which I assume is the goal for the JSR
regardless of whatever else we hope to achieve?
> I'm not at all sure I like the RESTlet API, which is quite likely
> because I still haven't looked at it ihn detail. But I would
> definitely welcome it as one possible starting point for this JSR,
> just as much as the current proposal from Marc and Paul.
I agree (in welcoming RESTlet as a starting point). I dont have any
experience with it either so can't comment about it.
Jerome, what is it that you feel jsr311 should do that Restlet doesnt (or
vice-versa) and what are your reasons for keeping them separate?
Again, if the stated goal of this JSR is "define a good mapping of
> POJOs to RESTful Web services", this seems just as backwards to me as
> most of the JAX-WS stuff.
Im not sure I understand what this means. =)