Stefan,
> I hope we don't start having a purely philosophical discussion ...
> that was not at all my intent.
>
> I believe that
> (1) we should focus on HTTP only, not any other theoretically
> possible but practically irrelevant REST implementation
IMO, as a higher-level API, JSR-311 doesn't need to refer to HTTP protocol
too explicitly. I feel that a better balance could be reached by staying
HTTP-centric but not unnecessarily excluding other protocols that could be
mapped to HTTP semantics.
> (2) we should follow HTTP's explicit and implicit constraints and
> architectural decisions as closely as possible
+1
> (3) we should make it extremely easy and convenient to build
> applications that use HTTP *correctly* - i.e. API users
> following the
> path of least resistance should end up with a Web application
> that is "RESTful", possibly without knowing or caring
+1
> (4) there should be nothing I can do with HTTP that I can't do with
> Java and the JSR 311 API
-1. HTTP defines several lower-level artifacts, like persistent connections,
requests pipelining, content ranges, authentication that don't necessarily
have to be supported at this level. It could be taken care of in lower-level
API or layers. It you want 100% control on the HTTP protocol, then I would
suggest to use another API/framework (Grizzly, MINA).
> Also, +1 on Jan's suggestion to incorporate the notion of container
> resources, although I have some sympathy if someone questions
> whether this is implied strongly enough in the HTTP spec.
Are you referring to Atom here? I'm not aware of any part of HTTP 1.1 that
addresses this aspect. That's definitely an interesting area but I would
leave that out for a first version. However, we could discuss about it to
make sure that nothing prevents us from adding support later one.
Best regards,
Jerome