Re: Pagination (ISSUE-42)

On Mon, Feb 16, 2015 at 12:19 AM, Tomasz Pluskiewicz <tomasz@t-code.pl>
wrote:

> Andrew,
>
> Range is a specific case. There was a discussion here about making the
> allowedValues thing extensible so that you could express implicit ranges
> etc. On the other hand you could simply enumerate the values ad fallback.
>
> Regarding 'induvidual', I do not agree with you. I see where you are
> coming from though. The term does in fact come from OWL, but is it really
> so confusing? We are not talking about law or any other context. Hydra is
> about hypetmedia and REST. In this context individual (Resource) seems
> quite appropriate to me. What term would you propose as an alternative?
>
> I may have misunderstood the context of the issue, so please confirm to me
the intent. If the intent of the issue was to provide a choice of specific
people then "allowedIndividual" makes sense, if the intent was to allow a
choice of other types of things, eg "PaymentType", "Account", "Product"
which are resources and not just a string value or number then the
"allowedIndividual" thing is exceedingly bizarre.

I was assuming the issue is about *general* support for enumerated values,
and I only saw mention of "strings", "numbers" and "individuals", and no
mention of other types or support for ranges, or even operations that could
be used to either check or obtain a collection for the allowed range. I
hope it was a misunderstanding of the applicability of the proposal on my
part.

This is the disconnect I see with Hydra and JSON-LD vs getting the job done
in developer land.  In developer land, you develop your api and then use
your api in your app to obtain scoped collections that get used to scope
values in properties on other resources, in 99% of cases the client
understands the domain model a-priori. In the view layer this may take the
form of a select box, check boxes, number ranges, slider or a type-ahead
field with suggestions depending if the carnality is high or not,
importantly it is an A-PRIORI user interface design consideration. You just
do it and it works and the job is done with no strange concepts or
ill-fitting approaches.  Hydra doesn't seem to offer real world solutions
currently and the proposals seem limited to theoretical uses, or perhaps
just the generic client / hydra console (what I call "the registry editor
of the internet use case"), not contemporary applications being developed
today. Given I have to solve so many things myself (as would anyone else) I
can't say there is currently a compelling interoperability advantage to
using Hydra, (unless your app is the Hydra console) , so we truly are
better off doing proprietary apis that have a superior form factor for OUR
applications rather than being constrained to Hydra designs.

I hope I am wrong, but it is starting to look like Hydra can't really offer
anything reasonable that I can use in modern applications without having to
break out of it and just do what I do already. Honestly I could care less
that expressing things in Hydra means the Hydra Console can provide a
rudimentary UI for my API since I can generate a better one from my
database schema. I want MY applications to work at a superior level to what
the Hydra console or any generic client provides and I am sure everyone
else here does too since you can't really say 'go use the hydra console' to
a user as your front end. Good user interfaces require a-priori knowledge
of the domain model and humans dedicated to making user interface design
choices so I am not sure what Hydra ultimately gives us besides an
impoverished api documentation vocabulary.  I say impoverished because
there are much better ways to document and describe API's that better
assist integration by developers and UI designers.

I also believe that Roy Fieldings "Hypermedia is the engine of application
state" has limited applicability to contemporary web applications. Today's
applications are a mash-up of many distinct hypermedia sources using
multiple API end-points and persistent local state that is NOT determined
by the last hypermedia request. It is absurd to think the api endpoint for
twitter can somehow know the full application context and tell my client
app where it can go next given within my app a twitter feed is just a minor
component on the users profile. My intelligent application decides what the
available transitions are at any point in time, and presents the options in
a carefully designed UI, NOT the myriad of resource endpoints where data is
obtained for rendering the view. The hypermedia returned from a single api
endpoint is not the full application context, it cannot provide all the
valid transitions for my application yet we keep pursuing this approach
like its the early1990s.  I think the sooner people realize this, the
sooner we can all move on and design interoperability standards that work
well for real world intelligent clients and focus on what allows us to
support reusable tooling/plumbing. Paged collections are an example of the
fallacy of "Hypermedia is the engine of application state" when we include
first/last/next/prev transition links as if the collection endpoint is
driving the application UI. A design based on offset/limit or indeed just
page/pageSize treats the api like just one of many possible data-sources
with direct addressing of ranges through templated request parameters. It
doesn't attempt to 'drive application state' and nor should it, a
collection is just a tiny wheel in a much bigger engine, typically an
engine with a-priori UI, transitions and sophisticated orchestration of
many disparate services.