REST APIをAPIラッパーに直接使用する利点は何ですか？

Question

どちらを選択する必要がありますか？

私はそれを見ている方法は、APIラッパーは非常に簡単に使用するが、私は見ていない何かのように感じるので、私を啓発することができますか？

Answer 1

RESTはクライアントをAPIから切り離すソフトウェア設計であるが、しばしばHTTPに基づいているため、単純なURI設計と誤解されることが多い。

RESTをサポートするAPIとクライアントを使用する利点は明らかです。クライアントは特にAPIに結合されていないため、リソースを別のエンドポイントに移動するようなサーバー側の変更を許容します。ブラウザが無限の数のWebページのコンテンツを表示できるように、真のRESTfulクライアントは同じ動作をし、RESTをサポートするすべてのAPIと通信できる必要があります。いくつかの処理ルーチンを動的に（特定のアプリケーションのプラグインに似て）検索するか、デフォルトの処理に戻す（エラーを報告するか、または未知のデータをプレーンテキストとして表示する）ことによって、新しいコンテンツタイプを処理する方法を学ぶことができます。

APIラッパーは、特定のAPIのみに限定されたクライアントを作成するためによく使用されます。これにより、クライアントは、サービスとの間で送受信されるメッセージのエンコード/デコードなど、APIとのやりとりに必要な特定のロジックを含むことができ、利用可能なすべての操作などをリストすることができるため、開発が簡単になります。多くの場合、URIエンドポイントは、プロパティを通じて注入されるか、アプリケーションにハードコードされます。また、コンテンツタイプはXMLまたはJSONに制限されていることが多く、レスポンスを扱う方法に関するルールはクライアントに直接ハードコードされています。ただし、これらの手順はすべて、クライアントをAPIに密接に結合します。 APIが変更された場合（またはさらにエンドポイントによって充実している場合）、APIラッパーは更新され、各コンシューマーに出荷されなければなりません。そうしないと、ユーザーはAPIを使用したり最新の機能を使用することができなくなります。

APIラッパーは、APIの使用目的に合わせて調整されることが多く、実装する方がずっと簡単です。ただし、ラッパーがこれらの変更自体を処理することができないため、API自体が変更されている場合には、定数更新も必要です。一方で、RESTクライアントは、クライアントが何らかの形で特定の応答の意味的な意味を知る（または学ばなければならない）ようになり、受信された応答にどう対応するかを推測しなければならないため、はるかに複雑になります。その一部は（少なくとも自動化された処理では）まだ活発な研究分野です。

どのような場合に使用するかを尋ねたところ：汎用クライアントを作成する必要がある場合は、RESTクライアントが正しいことを確実に行う必要があります。しかし、正しい意味論的処置を特定することは、これらのクライアントIMOの真のチャレンジンになります。顧客（またはユーザー）にクライアントフロントエンドを提供するだけで、API自体に大きな変更はないと考えられる場合は、ラッパーを実装する方がはるかに簡単です。しかし、そのようなクライアントをRESTfulと呼んではいけません！