Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion How should HATEOAS Links in a json response be handled and why?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mike Kelly  
View profile  
 More options Oct 26 2012, 2:15 am
From: Mike Kelly <mikekelly...@gmail.com>
Date: Fri, 26 Oct 2012 07:15:29 +0100
Local: Fri, Oct 26 2012 2:15 am
Subject: Re: [api-craft] Re: How should HATEOAS Links in a json response be handled and why?

Sent from my iPhone

On 26 Oct 2012, at 05:51, Jørn Wildt <j...@fjeldgruppen.dk> wrote:

> I have been thinking a bit about this issue and come to the conclusion that the HAL approach where rels are indexed in a dictionary has some problems. Let me try to explain:

> To lookup a rel-value, say "printable", a client programmer would do like this, since HAL is optimized for the simple/most-used use case:

>   var url = data._links["printable"].href;

> But what happens if the server decides to throw in multiple links for the same rel-value, for instance both PDF and Word representations of the printable stuff? Well, the above code breaks since data._links["printable"] would become an array instead of a single value.

> Now a robust client has to write code like this:

>   var url = null;
>   if (data._links["printable"] IS ARRAY)
>     then lookup in that array
>   else
>     select single value.

> Unfortunately the dictionary approach encourages programmers to write the simple client code, assuming there will only be one link for each rel-value. This means encouraging programmers to write code that will break when the server decides to throw in multiple links for each rel-value.

> A robust client would always have to write code that somehow respects that it may have to traverse an array to find the link it is looking for. So why not always use an array like this:

>   _links : [
>     { rel="printable", type="pdf", href="..." },
>     { rel="printable", type="word", href="..." }
>   ];

> In that way we encourage (force) client programmers to write code that always iterates through the link array - instead of encouraging them to write brittle code that will break later on?

This isn't a big deal. You should obviously avoid churn by getting the plurality right first time (usually obvious). In cases where you don't, then just treat it like you would any other breaking change - by introducing an additional rel. i.e. either pluralize the rel or if you dont like plural rels change it some other way and keep it singular.

Cheers,
M


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.