Re: Using Hydra in non linked data ReST services

Hi Karol,

Am 29.01.2015 um 14:18 schrieb karol.szczepanski@gmail.com:

> In general, my aim is to have a vocabulary, that would allow me to create a
> framework that would automatically generate ReST API documentation, which
> then can be used either by a generic client or by a proxy class generators,
> i.e. in C#, so the programmers won't have to focus on communication details
> but rather on data and processes. Something WSDL-like for ReST.

I am tempted to say: if you need that, there is WADL. But seriously: why
do you look at Hydra for code generation?

There are two ways here: allow to constrain every single bit and have
language mappings as in SOAP to decide what data types should be
generated for the target platform. Or use the html5 way of describing
possible input with a minimal set of types like Number, String, Date...
(see html5 form elements) and use a tolerant server which interprets the
input. Similarly on the client side - the browser works with nothing but
Strings.

In my experience, the power of WSDL does not work in practice. Real-life
services do not fully specify their contract and the client has to cope
with that somehow. Usually you find out at some point that values can be
null or not present sometimes, you learn how to interpret certain values
(you get a String, but you have to map it to something more meaningful) etc.

It might be better if we accept that this is how the internet works,
stick to few constraints and otherwise advise clients to cope with
uncertainties such as the ones mentioned above.

As Mike Amundsen puts it: over-constraining is a bummer :)

Note that in order to consume a website in HTML you do not generate a
client first. If you think of it, generating language-specific client
code does not feel right on the Web. Consuming a service should work out
of the box, without generating client classes per service, as with atom
feeds.

Best regards,
Dietrich

Received on Monday, 2 February 2015 17:40:30 UTC