W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

Re: Client POC

From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
Date: Wed, 18 Nov 2015 11:29:52 +0100
Message-ID: <CAEdRHi7b+5sL2e=0zqox+o34A+U7bdu-TS1qjFXBiKdn2q2RYg@mail.gmail.com>
To: Karol Szczepański <karol.szczepanski@gmail.com>
Cc: Hydra <public-hydra@w3.org>
2015-11-09 21:58 GMT+01:00 Karol Szczepański <karol.szczepanski@gmail.com>:

> I'm not familiar with Pomona (though I know NancyFX quite well), but indeed
> my implementation relies on conventions (with optional attribute
> overridings).

Pomona is something we've made to solve not having anything like WSDL
in a REST API. Pomona generates a schema server-side and through this
schema, a C# client DLL is generated that can be downloaded and used
in a client application.

> I wanted it to take some of the implementation burdain from the developer
> when implementing controllers.

Sounds a lot like one of the design goals of Pomona. :)

> Indeed, similar approach. URSA also tries to provide both old-school data
> contracts to co-exists side by side with strongly typed wrappers over RDF
> (using RomanticWeb) to make the transition from that old-school approach to
> RDF based one less stresful for the developers. That what's the demo
> actually shows - Persons are JSON serialized, Products are RDF datasets and
> the controllers are almost 1:1 copy with few tweaks.

Yea, it's an impressive demo!

>> Doesn't the new PagedCollection fix this?
>
> PagedCollection defines links to fixed urls (next, prev, etc.) in a given
> collection, but client is unable to craft direct links on its own.

Why would a client need to craft paging links on its own? Filtering,
ordering, etc., are of course dependent on user input and need to be
in the client's control, but paging?

>> Returning simple types is discouraged anyway, so I don't see that as a
>> big problem. RFC 7493[4] states:
>>
>>   For maximum interoperability with such implementations,
>>   protocol designers SHOULD NOT use top-level JSON texts
>>   that are neither objects nor arrays.
>
> But this states that in order for maximum interoperability with previous
> RFC.

No, not really. It states that to preserve interoperability with
existing APIs and libraries.

> And when it comes to interoperability I'm hoping Hydra and RDF
> to take responsibility for by defining what the API would like to
> express.

Yes, that's an important part of Hydra in its JSON-LD serialization.
But since you expressed a wish to return unwrappet simple types, I
thought it was fitting to reference RFC 7493 which explicitly states
that such a practice is discouraged. And I believe Hydra should follow
best practice and thus not go against any of the recommendations made
in RFC 7493.

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Received on Wednesday, 18 November 2015 10:30:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 November 2015 10:30:30 UTC