Apollo-link-rest: エンドポイントごとに「ヘッダー」を指定できるようにする

作成日 2019年02月05日  ·  11コメント  ·  ソース: apollographql/apollo-link-rest


エンドポイントごとに排他的なヘッダーを指定できるはずだと思います。

例:WordPress RESTAPIとWooCommerceREST API(v2およびv3)を異なるエンドポイントとして構成しています。 したがって、エンドポイントごとに異なるAuthorizationヘッダーを提供できるはずです。

enhancement💡 feature help wanted 🛠

最も参考になるコメント

@paulpdanielsこれは、デフォルトのエンドポイントとして認証ヘッダーを使用してWP REST APIを使用し、WooCommerce REST API v2とv3を別々のエンドポイントとして使用している例です。v3には認証が必要ですが、v2には必要ありません。

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,
});

全てのコメント11件

いい視点ね! おそらく、最初のヘッダー構成をヘッダー/ハッシュまたは関数にして毎回実行できるようにする必要がありますか? @efoken @paulpdaniels

それは理にかなっています、tbh私はそれが今どのように機能するかを考えました、しかし私は異なるヘッダー要件を持つ複数のリソースを持っている問題に対処していないと思います。

@efoken使用したい_how_の例はありますか。 典型的なユースケースがどのように見えるかを理解するためだけに。

@paulpdanielsこれは、デフォルトのエンドポイントとして認証ヘッダーを使用してWP REST APIを使用し、WooCommerce REST API v2とv3を別々のエンドポイントとして使用している例です。v3には認証が必要ですが、v2には必要ありません。

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,
});

これに関するニュースはありますか? 私はREST-LINKを使用していて、認証を必要とする独自のエンドポイントと、キーを必要とする別のサードパーティのエンドポイントを持っている状況にあります。

今これをどうやってやるのか例はありますか?

また、一部のエンドポイントでは認証ヘッダーが必要であるが、他のエンドポイントでは必要ない状況があります。 これを達成する方法が見つかりません。

これについて何か作業が行われていますか? 1つのエンドポイントに基本認証が必要で、別のエンドポイントにベアラ認証が必要な状況があります

誰かがこれに対する解決策をまだ見つけましたか?

これに対する回避策はありますか? また、さまざまなエンドポイントのヘッダーをカスタマイズする必要がある状況にあります。

これに関する更新はありましたか? 現在、エンドポイントごとに異なる認証とヘッダーを必要とするプロジェクトに取り組んでいます。 これに対する回避策はありますか?

ターゲットURLを分析し、URLプレフィックスに基づいてヘッダーを挿入/追加するcustomFetch実装を提供できるため、これは今日実行可能です。

その回避策がうまくいかない場合はアドバイスしてください。

このページは役に立ちましたか?
0 / 5 - 0 評価