Re: Client POC

Hi Asbjørn

Thank you for your input.

>Fantastic! While I don't have any feedback to give as of yet, I'll be
>sure to get my hands dirty with this source code and figure out how I
>can best use it to solve pretty much exactly the same problem. I hope
>it can be combined with Pomona[1], which is an HTTP API framework
>similar to ASP.NET Web API[2], but based on Nancy[3] and on a
>"convention over configuration" approach.
I'm not familiar with Pomona (though I know NancyFX quite well), but indeed 
my implementation relies on conventions (with optional attribute 
overridings).
I wanted it to take some of the implementation burdain from the developer 
when implementing controllers.

>The work we're doing in Pomona now is replacing the current
>serialization format from POCO JSON to JSON-LD and a more URI
>reference based approach. We're at the same time exploring the
>possibility to replace the current JSON Schema based type inference
>with Hydra. The plan is to also use Hydra as a basis for autogenerated
>GUI and user browsable (self hosted) documentation.
>I think URSA can help with many of these problems. So thanks for this! :-)
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.

>> 2. Another issue I had was with pagination. Again, API Documentation is
>> silent in this area.
>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.

>> 3. Hydra's model also doesn't fit to ... datatypes (in terms of RDF/XSD
>> datatypes). In order to denote that an operation returns values of type
>> xsd:string I had to elevate it to hydra:Class, which I think is not very
>> elegant.
>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. 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.

Regards

Karol

Received on Monday, 9 November 2015 20:59:20 UTC