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
transitions.
i.e. common things you might do to code as you evolve a service and its
implementation.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109