私はAndroidデベロッパーであり、RESTful API開発に関する知識もあります。現在、Dot Net Web APIを使用してAPIを構築しています。すべてうまくいきますが、私はまだデザインに関心があります。RESTful APIのベストプラクティス
ここで私が心配しているのは、「レスポンスコード」と「レスポンスメッセージ」以外に追加できる便利な要素のような、レスポンスのメタデータが正確に必要なことです。
私の2番目の懸案事項は、リクエストが非同期であるか、クエリであるか、またはその両方であることです。
最後に、JWTや基本認証などのステートフルな通信をステートレスにするためにどのような技術を使用すべきですか。
まず、Roy Thomas FieldingのArchitectural Styles and the Design of Network-based Software Architecturesの第5章を読んでください。 RESTのアーキテクチャ上の制約、要素、およびビューについては、最初に学習します。
ここで私が心配しているのは、「レスポンスコード」と「レスポンスメッセージ」以外に追加できる便利な要素のようなレスポンスのメタデータです。
RESTのアーキテクチャ要素の1つは表現です。表現は、クライアントが応答の解釈を可能にする。 RESTfulなHTTP表現の場合は、MIMEタイプによって表現されます。詳細は[2]を参照してください。 考慮すべきその他の側面は、URI、サポートされているHTTPメソッド、URLパラメータ、およびメッセージ本文です。私にとって
第二の懸念は、その要求が非同期またはクエリ、またはその両方であるべきです。
RESTのアーキテクチャ上の制約の1つは、クライアント/サーバーのアーキテクチャスタイルです。したがって、サーバーは同時に複数のクライアント要求を処理する同時要求を処理する必要があります。照会、メソッド、または関数が非同期に処理されても、RESTfulであることは関係ありません。
そして最後の懸念は、私はJWTや基本認証などのステートフルな通信を行うために使用すべきかの手法である、など
JWTと基本認証は、両方のステートレスな認証方法です。 「ステートレス」という用語は、クライアント要求が、サーバがクライアント要求を処理するために必要なすべての情報を含んでいることを意味します。
1）METAデータ - リソース表現は、Fielding自身で駆動されるHATEOASである必要があります。したがって、関連リソースlinks in meta dataを追加することを検討することがあります。
2）同期/非同期 - どのAPIが何をしようとしているかによって異なります。長期実行プロセスを呼び出す場合、非同期APIは当然の選択です。それ以外の場合は、Sync APIを使用してください。
3）ステートフルな通信 - statelessは、RESTアーキテクチャの制約の1つです。クライアントコンテキストは、要求の間にサーバーに格納されません。クライアントは、アプリケーションの状態を管理する責任があります。