Allow specifying headers per endpoint

[efoken]

I think it should be possible to specify exclusive headers per endpoint.

For example: I have WordPress REST API and the WooCommerce REST API (v2 & v3) configured as my different endpoints. So it should be possible to provide different Authorization headers for each endpoint.

[fbartho]

Good point! Possibly we should allow our initial headers config to be a Headers/Hash or Function to execute each time? @efoken @paulpdaniels

[paulpdaniels]

It makes sense, tbh I thought that’s how it worked now, but I guess I haven’t dealt with a problem having multiple resources with different header requirements.

[paulpdaniels]

@efoken do you have an example of how you’d like to use it. Just to get a sense of what a typical use case would look like.

[efoken]

@paulpdaniels this would be an example where I'm using the WP REST API with authorization header as the default endpoint, and the WooCommerce REST APIs v2 and v3 as separate endpoints – v3 requires authorization and v2 does not:

import { camelCase, snakeCase } from 'lodash';
import { RestLink } from 'apollo-link-rest';

if (typeof window === 'undefined') {
  global.btoa = str => Buffer.from(str).toString('base64');
}

const restLink = new RestLink({
  uri: 'https://example.com/wp/v2',
  headers: {
    authorization: `Basic ${btoa('client_key:secret_key')}`,
  },
  endpoints: {
    'wc-v2': {
      uri: 'https://example.com/wp-json/wc/v2',
      headers: {
        authorization: undefined,
      },
    },
    'wc-v3': {
      uri: 'https://example.com/wp-json/wc/v3',
      headers: {
        authorization: `Basic ${btoa('another_client_key:secret')}`,
      },
    },
  },
  fieldNameNormalizer: camelCase,
  fieldNameDenormalizer: snakeCase,
});

[DennisBaekgaard]

Any news on this? I'm in a situation where I use rest-link, and have my own endpoint which requires authentication and another third-party endpoint which requires a key.

Is there any examples of how to go about this now?

[brad-sobie]

I also have a situation where I need an authorization header on some endpoints but not on others. I can't find a way to accomplish this.

[Pearce-Ropion]

Has any work been done on this? I have a situation where one endpoint needs basic auth and another needs bearer auth

[kbudlla]

Has anyone found a solution to this yet ?

[pixelfuture]

Any workaround for this? I am also in a situation where I need to customize headers for different endpoints.

[bmholmes]

Has there been any update on this? Currently working on a project which requires different auth and headers for each endpoint. Is there a workaround for this?

[fbartho]

You can provide a customFetch implementation that analyzes the target URL and injects/appends headers based on a URL prefix, so this is doable today.

Please advise if that workaround doesn't work for you.

[fbartho]

Closing since a workaround is provided.

Happy to reopen this if people want to implement it. I'm not personally motivated to do so, as this would probably add complexity to the basic API and codebase.

[asura-asp]

@fbartho
Can you please provide an example how to accomplish the analyzes the target URL part?

You can provide a customFetch implementation that analyzes the target URL

Thank you.

[asura-asp]

Related #174

This is inconvenient but seems to work

const restLink = new RestLink({
 uri: "https://awesome-workatound-why-do.com",

 customFetch: (uri, options) => new Promise((resolve, reject) => {
    // console.log("customFetch uri was:", uri);
    const authHeaders = getAuthHeaders(uri);
     
    fetch(uri, { ...options, ...authHeaders })
      .then(response => resolve(response))
      .catch(err => reject(err));
  }),

...

[fbartho]

@asura-asp that’s a great implementation. You could alternatively skip the new Promise step, to simplify.

const restLink = new RestLink({
 uri: "https://awesome-workatound-why-do.com",

 customFetch: (uri, options) => {
    // console.log("customFetch uri was:", uri);
    const authHeaders = getAuthHeaders(uri);
     
    return fetch(uri, { ...options, ...authHeaders });
  }),
...

[flippidippi]

I feel like this workaround isn't friendly enough to close this issue. I def think things like headers and credentials should be set per endpoint and it would make it way more readable.

[fbartho]

@flippidippi — as I said before, I’m happy to reopen this if somebody feels motivated to work on a clean PR implementing this functionality w/ docs & tests.

I originally closed it, because I don’t feel the need to feature proposal tickets open if nobody is interested in implementing the feature in a clean fashion.