I would be surprised if there was anybody that is part of this EG that
is under the illusion that we are trying to create anything more than
"a new form of application deployment mechanism." Nobody is trying to
limit whatever REST may be.
Personally, I don't feel that by putting these classes and interfaces
in a package called "rest" is implying that they encapsulate the whole
REST architectural style, nor do I feel it would imply Sun's ownership
of the style.
I'd just like to see a sensible answer to the question "in what
package are these classes located?" It makes more sense to use the
name "rest" in for this, since that's the name of the architectural
style we refer to in all our discussions and design. Why is "rs" any
better? Isn't it short for "rest" anyway?
-Ryan
On 4/11/07, Roy T. Fielding <roy.fielding_at_day.com> wrote:
> On Apr 11, 2007, at 4:30 AM, Dhanji R. Prasanna wrote:
> > Paul/Marc: Out of curiosity, what exactly was ASF's objection? The
> > comment seemed to indicate they didnt want jsr311 to be perceived
> > as THE rest framework.
> > Does this mean they expect other standards/frameworks around rest
> > web services? Or that they feel rest is broader than just web
> > services (in which case could we do something like: javax.rest.ws?)
>
> It was my objection to the use of the name that I created in a way
> that would imply Sun's ownership of the style for the entire Java
> platform. My opinion is that there is very little chance that this
> JSR will produce something that is even compatible with a subset
> of the REST architectural style, let alone the entire system concept
> described by that style. While some people may find it convenient
> to associate this proposed API with a popular meme, doing so would
> be decidedly inconvenient for folks like me who already have
> REST-based implementations in multiple languages and multiple APIs.
>
> I find it interesting that anyone would think that annotations on
> object methods associated with POJOs would have anything whatsoever
> to do with REST. REST is all about data flows, mapping identifiers
> to representations, managing that mapping over time (resources),
> and expressing relationships between resources (links and metadata).
> If this annotated object API were called *the* REST API, that would
> seriously piss me off. If it is called something else, such that
> I can reasonably have a conversation about my dissertation without
> having a bunch of newbies think I was talking about this API, then
> I don't have any problem with people experimenting with a new form
> of application deployment mechanism like this one. I may even
> learn something from it, or perhaps combine it with some of the
> more flexible APIs (such as JCR or OSGi) to build the server-side
> of a system that could be RESTful as a whole.
>
> REST is an architectural style for network-based applications, not
> an API for server-based frameworks. It is therefore unreasonable
> to assign the name REST to any single group's server framework,
> no matter how well intentioned or capable that group may be.
>
> ....Roy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>