Re: Why the collection?

Jacopo, Tomasz,

I agree with you both. The building blocks are what I expect and nothing
more.

Hydra collections do not meet my basic use cases and I won't be using Hydra
when it dictates things I don't want.

Defining paged serial access collections like its the 1990s will be just
one reason why an ill fitting standard to be like Hydra will be ignored by
the majority of the development community.

To illustrate why that will be its fate, I for one surely cannot and will
not recommend Hydra when it doesn't align with the basic requirements of a
modern application ... requirements and rationales which I have detailed a
number of times, just to see the discussion rewound back to 'let's do
simple 1990s serial access paged collections'.  Great, ignore the
requirements of modern applications and you automatically fail 99% of where
the action is.

When a developer looks at Hydra they will see a collection design that
doesn't align with their requirements.  They then have to ask themselves do
I fight it and implement 'non standard' collections out of necessity, and
then face being non-standard and issues with toolkits and libraries?

The lowest risk approach is to simply use something else; if you can't
comply with the collection design in Hydra because it doesn't serve use
basic usability which we have ALL come to expect in modern applications
then why bother at at all? ... Developers will avoid using Hydra, they will
not make a rod for their back if Hydra goes against the grain of how they
need to consume large collections and related resources efficiently to
avoid 1+N queries.

The future of describing modern web APIs does not appear to be based on
anything related to Hydra when it takes such a naive approach to
collections. Better to say nothing than the current proposal.

The conclusion I have reached is Hydra does not work for describing APIs
for modern applications and seems to have no charter to do so. Its unstated
use case appears to be what works best for the generic Hydra console UI
(since that is single resource at a time client as per Roy Fielding's paper
and not intelligent, or able to consume multiple resources from multiple
endpoints simultaneously and is unable to handle offset/limit or random
access to a collection but just prev/next actions like the 1990s. The
objective of Hydra is to give dumb clients dumb transitions where the
resource is the tail wagging the dog). There is little value pursuing that
objective for most of the developer community who build intelligent clients
with friendly UIs where transitions are DESIGNED; with UIs that users
actually want to use; touch based interfaces where random access to
collections is needed and avoidance of 1+N queries for related information;
with state being a mash up of multiple resources from multiple endpoints
and services. If any of that sounds advanced, its not, its what your smart
phone or tablet does day in day out using JSON based apis that are NOT
described using Hydra.

I will now spend my efforts on more productive outcomes rather than the
naive approaches and proposals embodied in Hydra. In internet terms the
early 1990s was a long time ago, Hydra needs to be relevant not just for
today's clients and APIs but where things are headed and I see little
recognition of that in the proposals.

Best of luck to you all, I'm done here.
On 7 Mar 2015 05:32, "Jacopo Scazzosi" <jacoposcazzosi@gmail.com> wrote:

> Hello Tomasz.
>
> I must have missed your emails, sorry about that.
>
> any kind of collection (or partial view) could be modeled with simple
>> building blocks like Operations and Links
>
>
> I completely agree. I think Hydra should provide a way to describe HTTP
> APIs without trying to dictate the semantics of their data structures. To
> me, it feels as if this is either already possible or close enough.
>
> Coming up with a standard approach to ld-collections feels like an
> orthogonal concern.
>
>
>
>
> --
>
> Jacopo Scazzosi
> Developer
> http://www.jacoscaz.com
>
> On Fri, Mar 6, 2015 at 6:48 PM, Tomasz Pluskiewicz <tomasz@t-code.pl>
> wrote:
>
>> Hi Jacopo
>>
>> These is exactly what I have been trying to say some time last month. I
>> think that we are going into specific design of a collection. My point was
>> similar, that any kind of collection (or partial view) could be modeled
>> with simple building blocks like Operations and Links. Any specialized
>> terms sometimes seem a little out of place in a general-purpose hypermedia
>> vocabulary I think Hydra is.
>>
>> On the other hand non-linked hypermedia approaches all sport some notion
>> of a collection, though I would very much draw any conclusion from that
>> simple fact.
>>
>> Thanks,
>> Tom
>>
>>
>> On 2015-03-06 12:32, Jacopo Scazzosi wrote:
>>
>>> Hello Thomas.
>>>
>>> Thanks for the clarification. Isn't playing with lego exactly what we
>>> are all doing with RDF vocabularies and ontologies, though?
>>>
>>> In my learning process I've already encountered quite a few of them
>>> (skos, rdf(s), hydra, foaf, xlmns, owl, schema, ...). It already feels
>>> like
>>> "playing lego" (just as picking and assembling the right components
>>> for an API's underlying architecture does).
>>>
>>> Also, if the goal is to "describe Web APIs" from a practical,
>>> what-can-you-do-with-this point of view, then wouldn't Hydra benefit
>>> from the separation of concerns obtained by delegating the semantics of
>>> collections to dedicated vocabs?
>>>
>>> I'm absolutely no expert but collections seem to be so context-specific
>>> that even you guys are experiencing some difficulties in finding a common
>>> ground - hence my considerations.
>>>
>>> Cheers.
>>>
>>>
>>
>>
>