2つの異なるURLを持つ2つの環境(テストと本番)があるとします。また、異なるヘッダー値を必要とする2つのサービス(serviceAとserviceB)があります。Postmanの4つの環境でこれに対処できます。
ここでは、URLとヘッダーの両方が重複しています。別のURLを追加すると、合計6つの環境が必要になります。
また、ヘッダー値の変更が必要な別のサービスを追加すると、別の3が必要になります。
どうすればこれを回避できますか?複数の環境をアクティブとして選択できれば素晴らしいと思います。次に、たとえば「ステージング」と「serviceC」の横にチェックマークを付けることができます。
Pawに固有のソリューションの場合:
Paw makeには、環境ドメインの概念があり、環境値をより簡単に制御できます。基本的に、環境ドメインは、同じ環境値の表現である複数の環境を持つことができます。
あなたの場合、3つの環境ドメイン(serviceA、serviceB、serviceC)を持つことができ、そのために3つの環境(テスト、ステージング、本番)を持つことができます。
一般に、これにより、複数の環境ドメインを1つのリクエストで一緒に使用できるため、多くの柔軟性が得られます。例えば、一つは想像Server
異なる環境(と環境のドメインをus-east-1
、us-west
と言うと組み合わせることができ、...)、Version
環境ドメインは(v1.0
、v1.1
、v2.0
、など)、およびバージョン2.0作品かどうかを確認するために単一の要求にそれらを組み合わせて私たちに-east-1など。
Postmanに固有のソリューションの場合:
いくつかの{{}}
複雑さを使用して、いくつかの環境を過給することができます。環境変数は相互に参照できます。
ここで、{{some-important-header}}
どこかで環境変数を参照すると、実際には、、{{{{mode}}-some-important-header}}
この場合は{{test-some-important-header}}
、、またはが参照され-1
ます。あなたはモードを変更するたびに、環境変数の値を変更する必要がありますmode
ように、正しい値にproduction
、またはstaging
。
これは最もクリーンなソリューションではありませんが、結合による多数の環境の作成を回避します。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加