W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

RE: My opinion about hydra vocabulary

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Fri, 6 Jun 2014 17:47:27 +0200
To: <public-hydra@w3.org>
Message-ID: <02e201cf819e$9facedc0$df06c940$@gmx.net>
On Friday, June 06, 2014 9:29 AM, László Lajos Jánszky wrote:
> > 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

No, I never got it.


> available here:
> https://github.com/lanthaler/sfHydraDemoApp/blob/master/src/ML/DemoBundle/Entity/Use
> r.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?

It is a prototype, nothing more, nothing less.

The main point was to illustrate that it is easy to integrate Hydra in a current Web framework. While we can certainly discuss whether the architecture is perfect (is there something like a perfect architecture?), I think it is beside the point. A fact is that a lot (most?) JSON-based services are built using such an approach. The simplest way to upgrade such service is to just add a couple of annotations. That's the functionality that the HydraBundle enables and that the demo app you reference above leverages.


> 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

Definitely not. In fact, you should decouple your internal representation from the external representation as much as possible.


> 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.

Sure. Hydra certainly doesn't dictate how the server has to be implemented. It just describes the interfaces (aka service surface) the server exposes.


HTH,
Markus


--
Markus Lanthaler
@markuslanthaler
Received on Friday, 6 June 2014 15:47:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC