I think general questions like this are more appropriate
at the rest discussion group [1].
However, in answer to your question I'd say you should avoid
fine grained RPC style access to resources ( getEmployeeAge() ) and
instead stick to a more coarse grained view ( Employee getEmployee() ).
IMO best practice (or rest practice ;) also means keeping things simple.
Every resource (URI) you expose should have an ID and can offer many
representations. If you break down a resource into two many URI's like
you do with the fine grained view, things start getting complicated.
It's ok to have associated sub resources in the same URI space, but
that's more like modeling parent/child relations.
You particular problem also conflicts with information hiding:
Someone did send you a link to a CMS backed website. The link points to
an article section. Three weeks later you'd like read that part again
but the author restructured the article, you'll get a 404 on that
section. However the top level link to the overall article still works.
I think the same applies to your employee resource.
Just my 2 cents. But i have to admit don't have that much practice
with RESTful approaches. But check out the discussion group.
[1]
http://groups.yahoo.com/group/rest-discuss/
Regards, Heiko
On Thu, 2007-11-29 at 04:18 -0500, Liu, Jervis wrote:
> It is mentioned in JSR-311 section 3.1.2 that "An implementation MUST
> include pre-packaged EntityProvider implementations for the following
> Java and media type combinations: java.lang.String All text media types
> (text/*).". However I don't see any places in the spec mentions about
> the conversion between a Java primitive types and an entity body. It is
> a common use case that I want to map my SQL "select employee _age from
> employee where employee _name='john'" to a java method "int
> getEmployeeAge(String employeeName)" then expose this as a RESTful
> service. Is this the correct way to do REST, or I am still having my
> head in a Service-oriented world instead of resource-oriented? Anyway,
> let's say my use case is indeed valid, in this case what content type I
> shall use to return an int type so that the client can make sense of?
>
> Shall I return int using content type "text/*"? In the case of returning
> String, as long as the client knows the returned content type is text,
> it should always be able to marshal the response body to a String
> without making any further assumptions. However this does not work for
> int type. If only information I have on the client side is the content
> type "text/*", it would be impossible for me to make sense of the
> response, is it a int type, is it a double type? I simply do not know.
>
> Or maybe, return an int using "text/*" is not a good practice in the
> RESTful world, using "application/xml" would be better. Can I say
> exposing a java method whose signature is " int getEmployeeAge(String
> employeeName)" is not a good practice, you should always wrap the result
> in a Java object instead, e.g., like " Employee getEmployeeAge(String
> employeeName)"? Or maybe, the JSR-311 runtime can go a little bit fancy,
> for example, it can generate a wrapper automatically on top of java
> primitive types so that the returned result is a valid an xml doc.
>
> Any thoughts would be highly appreciated. And should not JSR-311 spec
> include a section to describe how to do the conversion between a Java
> primitive types and an entity body?
>
> Thanks,
> Jervis Liu
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>