Re: W3C standardization process

> What kind of tooling would you need/like to have? What programming
language
> are you using to implement your API/clients?

We're using Java for the API. We need to be able to treat the client
response much like an XML DOM - the data would flow through a couple of
layers in our architecture, and each layer should have the capability to
modify the response.
Siren4J provides a FluentBuilder API which allows us to construct a Siren
payload easily enough, but doesn't seem to give the capability to modify
it. There are other similar libraries for pure JSON handling, which again
either assume you want to map to / from a POJO and a JSON representation,
or allow you build a JSON object and convert it to a String. But we haven't
yet found anything that would allow us to manipulate a JSON DOM like we
could an XML DOM. We haven't found any library that understands Hydra by
default.

Hydra gives us some nice features from a testing perspective - the
"returns" feature allows us to validate our API output automatically, and
we can re-use the same validation to apply to client-supplied data for the
"expects" side of things. It also seems that we can use the same Hydra
context as both our test blueprint and our developer documentation, which
is nice.

It also seems that we can pass better semantics back to the clients (to
support i18n, l10n, and accessibility issues) than Siren allows. (Because
you don't seem to be able to assign a Siren Class to a Siren Property, only
to an Entity.) I plan to raise that on the Siren Google Group later.

Where Siren seems to have an advantage is where we want the API to change
behaviour at runtime depending on the current server state, i.e. a Class
should be POSTable sometimes but not alway;, or a POST may return one Class
in some circumstances, and another Class at other times (and the two
Classes are not both semantically subclasses of the same super Class). A
static Hydra context doesn't allow this. (We have been thinking about
serving different Hydra contexts at different times to get round this, but
I'm not convinced taht's a god way to go.)

And because of the lack of an upfront API document, I suspect Siren client
developers are more likely to code generic clients that can cope with any
Siren response, whereas a Hydra client developer might code a client
specific to our Context.


James.


On 23 January 2014 15:48, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Wednesday, January 22, 2014 8:58 PM, James Langley wrote:
> > I'm looking into the possibilities for implementing a RESTful API at
> > the moment. We've been thinking about what data format / media type we
> > would use. The two front-running candidates for us are Siren and
> > Hydra. Neither seem to have great tooling support or plentiful
> > brilliant examples to learn from at the moment.
>
> What kind of tooling would you need/like to have? What programming language
> are you using to implement your API/clients?
>
>
> > I'm wondering whether the fact that JSON-LD has become a standard will
> > make it more likely that tools will be developed for it, which could
> > help with getting tools in place for Hydra; or whether the simpler
> > format of Siren and existing libraries (such as Siren4J) means we will
> > see more of a community forming more quickly around Siren.
>
> I don't know but I think that being a W3C standard and having already been
> adopted by Google, BBC, Globo.com and the likes JSON-LD and thus indirectly
> Hydra has some advantages here.
>
> I agree that Siren is slightly simpler but that results, in my (biased)
> opinion, in degraded extensibility and reusability. You basically end up
> creating snowflake APIs. All of them are similar but don't share concepts
> such as classes or fields (in Siren-speak). I know Kevin is on this list
> and
> I'm sure he'll chime in if I'm wrong.
>
> Hydra, on the hand, hugely bets on reusability and linked data principles.
> Often you won't need to define your custom data model. Instead, you would
> just reuse something like Schema.org. All that's left for you, is to
> describe the behavioral model (as I like to call it). This has the
> advantage
> that the contract is owned by a third party and thus reduces the risk to
> expose implementation details or to tightly couple clients to the server.
> They are coupled against a shared vocabulary instead. I gave a talk about
> this last year, both the video [1] and the slides [2] are online. For a
> more
> abstract discussion, you may be interested in the paper at [3] and the
> corresponding slides [4].
>
>
> > There are of course other factors in the decision besides tooling
> > support.
>
> Definitely.
>
>
> Cheers,
> Markus
>
>
> [1] http://bit.ly/sl-portland2013-video
> [2] http://m.lanthi.com/sl-portland2013
> [3] http://m.lanthi.com/wsrest2013-paper
> [4] http://m.lanthi.com/wsrest2013-preso
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>