New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hrRoot insert custom headers #4

Closed
XVincentX opened this Issue Apr 16, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@XVincentX
Contributor

XVincentX commented Apr 16, 2015

Hey,
I was trying to use this great library for a personal project.
The reference API can emit hal or siren payload based on the Accept header.
From the examples that I saw here, looks like

start = hrRoot('http://reference.com')

is the way to start working with it.
But how can I set a custom header before issuing the request itself?

petejohanson added a commit that referenced this issue Apr 17, 2015

Bump to hy-res@0.0.6, and minor tweak to hrRoot API.
* Bump hy-res dependency to get HyRes.Root constructor changes.
* Switch hrRoot to return the HyRes.Root object directly (which is
  really just a HyRes.WebLink. Will allow setting additional properties,
  in particular `type` on the link before following. Should address Issue #4.
@XVincentX

This comment has been minimized.

Contributor

XVincentX commented Apr 17, 2015

Hello,
thank you very much for the prompt reply and fix.
Would be possibile it on bower as well?
Keep going the great work!

@petejohanson

This comment has been minimized.

Owner

petejohanson commented Apr 17, 2015

@XVincentX I should have time to push a new release of angular-hy-res to Bower tonight.

@petejohanson

This comment has been minimized.

Owner

petejohanson commented Apr 19, 2015

@XVincentX The Accept header sent by angular-hy-res in sample app happens because the links that initiate those requests include a type value. See https://github.com/kevinswiber/siren#type for Siren or http://tools.ietf.org/html/draft-kelly-json-hal-06#section-5.3 for HAL. Ultimately, this is part of the RFC5899 Web Linking standard.

For modifying the Accept header sent when fetching the root of the API, you have two options using the just-published v0.0.13:

  1. I updated hrRoot to actually return a WebLink instance itself, which can then be followed. If you set the type value on the WebLink instance, when you then invoke follow(), it should work as expected, e.g.:

    var rootLink = hrRoot('http://reference.com');
    rootLink.type = 'application/hal+json';
    var root = rootLink.follow();
    
  2. You can use the HTTP options that are passed to the underlying $http AngularJS service, like:

    var root = hrRoot('http://reference.com').follow({ headers: { Accept: 'application/hal+json' } });
    

One option I've considered is creating some "default options" that would allow specifying something like: hrRoot('http://reference.com', { automaticAcceptHandling: true }) that would populate the Accept header sent based on the registered extensions. Thoughts?

@XVincentX

This comment has been minimized.

Contributor

XVincentX commented Apr 19, 2015

Hey,
thank you for the prompt update, I am going to try that right now.
The auto detect option would be very interesting.
The only question that comes into my mind actually is: what if I've registered both extensions (siren and hal, for example). Which Accept-Header would you send? Throwing an exception? Sending the first one given the registration order?

@petejohanson

This comment has been minimized.

Owner

petejohanson commented Apr 20, 2015

@XVincentX I think you would send an Accept header with both, in the order they are registered. If we wanted to offer a bit more flexibility there, it could add a q parameter based on a quality property on the extension...

@XVincentX

This comment has been minimized.

Contributor

XVincentX commented Apr 20, 2015

I agree for both types in the Accept header.
IMHO I'd skip the quality parameter.
Thank you

@XVincentX

This comment has been minimized.

Contributor

XVincentX commented Apr 20, 2015

I guess we can close this.

@XVincentX XVincentX closed this Apr 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment