- From: László Lajos Jánszky <laszlo.janszky@gmail.com>
- Date: Fri, 6 Jun 2014 09:29:20 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
> I just wonder why you might wanna do that? It just makes life for everyone much more complicated. I think a general REST solution should allow to send different representations of resources and different media types. So it was not about my personal interest. > László, you keep forgetting to CC public-hydra@w3.org. This is important as otherwise only I will receive your messages. Ohh, thanks for the advice. I sent a reply to Kingsley Idehen, but I don't think you got it. Shortly it was about the demo application available here: https://github.com/lanthaler/sfHydraDemoApp/blob/master/src/ML/DemoBundle/Entity/User.php . It is far from a perfect architectural approach, because you confuse hydra resources with orm entities and you put presentation, business logic and data access into the controller. Was all of these because you wanted a fast, simple example, or is this your recommended architecture? Btw. I don't think it is necessary to have resource classes and objects on the server in order to handle a REST request. For example by many architectural approach (ports and adapters, onion architecture, clean architecture, n-tier architecture) the REST is just a delivery method which has nothing to do with the application logic, it just delivers the requests to it, that's all... For me REST is just another way to express operations in a web interface. For example by SOAP you send `POST example.com/SayHello {subject: "John"}`, by REST you send `GET example.com/helloMessage?subject="John"` to get a "Hello John" response. On the server side you can handle both request with a `HelloController.sayHello(subject)`, and construct just the response string. In this case there is no need to have a resource class like HelloMessage... Maybe this is supported by hydra, I just don't understand it well enough.
Received on Friday, 6 June 2014 07:29:48 UTC