Marek,
le me cite Mr Fielding's dissertation...
"The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations."
...which unambiguously says that there is no separation in controller and model (and, BTW, between the lines, that RPC is not REST). I do not see a need for this in JAX-RS, unless one tries to do RPC.
Regards
Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Dienstag, 8. November 2011 19:40
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Improving Hypermedia Support
>
>
>
> 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
> >