Re: JSR311: Feedback from W-JAX presentation

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 08 Nov 2007 10:59:49 +0100

Stefan Tilkov wrote:
> On Nov 7, 2007, at 7:56 AM, Paul Sandoz wrote:
>> Ryan McDonough wrote:
>>> @Stateless
>>> @UriTemplate("/people")
>>> public class PeopleServiceBean {
>>> @GET("{id}")
>>> public Person getPersonById(@UriParam("id") String id) {...
> Won't the most common case be that the return type is "Response"?

Yes, if caching/preconditions are required.

In general when developing such RESTful services the details of the Java
method signatures and class hierarchy relationship of resource classes
do not impose on the service definition (since by definition it is
uniform). Thus one can easily refactor an implementation and modify the
service without affecting breaking existing clients, for example:

  - adding another GET method to produce a different media type;

  - adding create/update functionality

  - adding more sub-resources as sub-locator methods;

  - changing resource classes to inherit from an abstract class with
    common behavior; or

  - breaking down the URI hierarchy into separate reusable classes.

  - changing a representation to have additional URIs for new state

i.e. common things you might do to code as you evolve a service and its


| ? + ? = To question
    Paul Sandoz