Re: Hydra compared with JSON API, other specifications

Interesting thread, I have used Siren (vastly extended/modified) in the 
past, but I am more inclined to JSON-API at this point, despite it's 
deficiencies. I will grant, that a large part of this may be ignorance 
and a simple desire to get moving on our various client projects (but at 
least I am trying something right?) and a large part of my ignorance is 
a complete non-desire to dive into a rabbit hole of deeper unnecessarily 
esoteric (for my our client use cases I feel) standards like 
Triplestores and SPARQL.

Maybe Triplestores are the best way to describe interactions for all 
domains in the world, but...I have never worked on a software 
application that necessitated modeling the world. Maybe SPARQL is better 
than SQL, but I have never used a RDBMS that supported SPARQL (that I 
know of, lol).

I am simply trying to provide APIs that communicate its resources and 
the available capabilities of these resources in a consistent fashion. 
Doing that in-band, so that the server communicates this data in the 
context of the current request (user), has been key.

Not trying to throw stones here, I would love to have a conversation 
with somebody in the know that could break it down for me (and I have 
spent too much time pouring through all of the specs).

Best,
Paul

> Thomas Hoppe <mailto:thomas.hoppe@n-fuse.de>
> January 11, 2016 at 1:37 AM
> Hi Martynas, Kingsley
>
> thanks for your feedback.
> I agree that some if not most points on this slide are no longer valid,
> that's why the heading says "".
> This slide should describe how the Sem Web stuff was in the past
> _and_ how it was perceived by industry people which were not involved 
> with these technologies.
>
> BG, Thomas
>
> On 01/06/2016 01:29 PM, Martynas Jusevičius wrote:
>
> Martynas Jusevičius <mailto:martynas@graphity.org>
> January 6, 2016 at 4:29 AM
> Nice slides indeed, however I would disagree about most issues of the
> Semantic Web:
>
> Triplestores:
> - immature,
> - slow,
> -only few implementations (very few commercial).
>
> SPARQL:
> - complex
> - few implementations,
> - inappropriate for many real-world problems.
>
>
> In my experience, SPARQL is intuitive (much more so than SQL) and
> appropriate for very many real-world problems. And there's plenty of
> implementations, both commercial and open-source:
> https://en.wikipedia.org/wiki/List_of_subject-predicate-object_databases
>
> Colin Maudry <mailto:colin@maudry.com>
> January 6, 2016 at 4:04 AM
> Hi Thomas,
>
> Great document, both concise and clear for a techie audience. Thanks!
>
> Colin
>
> On 06/01/16 10:09, Thomas Hoppe wrote:
>
> Thomas Hoppe <mailto:thomas.hoppe@n-fuse.de>
> January 6, 2016 at 1:09 AM
> Hi Paul,
>
> I compared Hydra to other approaches in general a bit here:
>
> http://vanthome.github.io/rest-api-essay-presentation/rest_apis.html#28
>
> BG, Thomas
>
> On 01/04/2016 01:14 PM, Paul Mackay wrote:
>
> Paul Mackay <mailto:paul@folklabs.com>
> January 4, 2016 at 4:14 AM
> Hi,
>
> I’m iterating on a couple of API projects and have been reviewing the 
> status of current API specification projects. JSON API 
> (http://www.cerebris.com/blog/2015/06/04/jsonapi-1-0/) reached v1.0 
> earlier this year and is more comprehensive than HAL (see 
> http://jsonapi.org/faq/). I suspect Hydra could be even more flexible 
> and comprehensive in terms of defining an API. However within the JSON 
> API community that spec is being promoted as an anti-bikeshedding tool 
> (avoid lots of debate about small issues) and yet getting to 1.0 
> involved a lot of bikeshedding!
>
> Has there been any comparisons between JSON API and Hydra, and what is 
> behind the design choices of Hydra? I suppose a similar FAQ for Hydra 
> along the lines of why it goes beyond other API framework 
> specifications would be great :)
>
> Thanks
>
> Paul
>
>
> -- 
> Paul Mackay | 07761 050542 | www.folklabs.com <http://www.folklabs.com/>