RE: Express "go to specific page" for a collection

On 11 Jul 2014 at 09:53, Philipp Zins wrote:
>> Isn't the browser a client?
> 
> Yes, sorry. I often use the word "client" for the (web) app that
> consumes the API to distinguish between the app and the browser.
> Sorry, for the confusion.
> 
>> No, because the browser does that for the user. The normal user also
>> doesn't look at the HTML source code as the browser handles that
>> for him too.
> 
> Well, the browser does that for the client (say: app), too. I'd
> definitely say that the use sees and consumes the HTML document. Maybe
> it doesn't look like source code for the user, because it is a
> graphical representation rendered by the browser, but with some
> imaginary you could also say that the client doesn't look at the
> JSON-LD document, but some binary representation :) For me it
> makes sense to say: What HTML is to the user is JSON to the
> app client and HTTP header should be meaningful to the browser.

True. But it depends on which layer you are. If you are a user operating a browser, you interact with the representational layer, the graphical user interface. Obviously at that layer, the visual representation matters. On the other hand, if you are a client library that is controlled by an application instead of a user, there's no need for a graphical representation. Thus, it would be overkill to exchange visual information in the messages between the client library and the server it accesses.

What often makes sense in cases like this is to have a separate "knowledge base" which defines the visual representation for the exchanged data. So, simply speaking, you define somewhere that whenever a schema:Person is retrieved, it is displayed to the user using a specific template. In other words, you bind schema:Person to a specific template. That binding (and the template) can of course be controlled by the server if it also delivers the app (as it does in the case of a single-page web application). From the client libraries perspective however, retrieving that representational information is just another ordinary API call.


>> Depends on what exactly you mean by "relative to their content". If you
>> mean visually, then I have to disagree. IMO an API format should just
>> express the raw data, not the visual representation thereof. There's no need
>> to reinvent HTML in JSON IMO.
> 
> No, I don't mean that in some visually way. What I mean is that it is
> beneficial to embed links directly into a resource. You get mostly
> links with no templating (say: place "/users/1" and "users/2" inside
> "users[0]" and "users[1]" instead of placing "/users/{id}" somewhere
> in the root of the payload), you can use different links for similar
> resources (DELETE "/users/1" but not "/users/2"), etc.

Great, so we are on the same page. Excuse my excursion above but I thought it would nevertheless make sense to mention that in this context.


>> If you already have a simple Web API, we could also discuss concretely
>> how to convert it to Hydra together if you want.
> 
> I definitely would like to do that, but I think we still need some
> weeks to work on our API to settle some things.

Just let us know when you are ready


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 11 July 2014 09:19:52 UTC