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.


Markus Lanthaler
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