データソースの上にビジネスロジックを追加するWebサービスがあるとします。このサービスの各APIはほとんどのように見えます-一連の制約が与えられた場合、これらの制約を満たすデータソースからのアイテムを提供します。APIからデータソースの「ビュー」を取得したと言えます。
ここで、時間の経過とともに、データソースに対してさまざまな種類のビューを返すように求められます。「十分に異なる」ビューごとに新しいAPIを追加するか、ギアを切り替えて、目的のビューの種類を指定するパラメーターを取得するgetFooDataView()APIを提供するオプションがあります。どちらの方法に行くかを決定するために、いくつかの競争圧力があります。
- あなたのサービスの既存の大きなクライアントは怠惰であることを好み、データの新しいビューが必要なときに新しいAPIまでコーディングする必要はありません。
- ただし、一部のリクエストパラメータ(制約)は一部のビューでのみ意味があり、他のビューでは意味がありません。「XYZビューが必要な場合は、 "foo"パラメータを設定すると、APIコントラクトを緩くする必要があります。一部のビューではそうであるとしても、 "foo"を必須パラメーターにすることができないという残念な副作用があります。
- 新しいクライアントがサービスを活用したいというケースはますます増えています。どちらがより混乱するかを決定することはできません-異なるがより厳密に定義されたAPIと、パラメーターのどの組み合わせが本当に必要なものを提供するかを知る必要がある1つのAPIを選択する必要があります。
これを抽出するために、既存のAPIのバリエーションとは対照的に、何かが独自のAPIである必要があるという線を描くのはいつですか?2人のクライアントの要求を意味的に区別する理由については、協力しなければならない人によって見方が異なるため、この問題についてコンセンサスを得るのは難しい場合があります。また、将来のクライアントがサービスを利用するのが極端に難しくならないようにする必要もあります。この種の選択を行うためのいくつかのベストプラクティスは何ですか?