On 11/08/2011 06:51 PM, Markus KARG wrote:
> Marek,
>
>> - perhaps it is my misunderstanding, but I don't agree that JAX-RS
>> resource classes should be tied to resource entities.
>> Perhaps it was an unfortunate choice of the name, but JAX-RS resource
>> classes are conceptually controllers, not models.
>
> I understand you view, but yes, the name is the problem. A resource is a model object, not a controller object. If you address http://foo/bar, you expect bar to be a model object (a document), not a controller (a web server software). But a second point is that in many cases we noticed that making resources as models is beneficial. I understand MVC and other layer models, but sometimes "real-world OOP" is superior. In the case of linking other entities for example. See, if there is a bar in foo (like above) and I want to link that but don't know the URL, I can just set @Linkable to the FooBar resource. If you do not make resources as models, you cannot do that -- and have to invent a strange wheel, as http was never intended to be MVC...
The way I see it is that resource methods in JAX-RS resource class are responsible for processing HTTP requests targeted
to a URI-identified resources as well as returning a proper resource representations in a form of HTTP responses. That,
to me, sounds like a controller functionality primarily. Sure, in some cases it may be practical to include the model
logic directly in a JAX-RS resource class, but a typical JAX-RS resource class still contains code focused on updating
some externalized state (model class, DB, ...) as well as it does not return self in response to a GET request. Also,
users don't need to create a new JAX-RS resource class instance for handling every single URI in the application URI space.
The external resource-oriented view of a JAX-RS application does not necessarily need to match the internal design.
Marek
>
> Regards
> Markus
>