私は Android 開発者であり、RESTful API 開発の知識も持っています。現在、Dot Net Web API を使用して 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 パラメーター、およびメッセージ本文です。
私にとっての 2 番目の懸念は、要求が非同期であるか、クエリであるか、またはその両方であるかということです。
REST のアーキテクチャ上の制約の 1 つは、クライアント サーバー アーキテクチャ スタイルです。したがって、一度に複数のクライアント要求を処理するには、サーバーが同時要求を処理する必要があります。クエリ、メソッド、または関数が非同期で処理される場合、RESTful であることに問題はありません。
そして最後の懸念は、JWT や基本認証などのステートフルな通信を行うためにどの手法を使用する必要があるかということです。
JWT と基本認証はどちらもステートレス認証方式です。ステートレスという用語は、サーバーがクライアント要求を処理するために必要なすべての情報がクライアント要求に含まれていることを意味します。
1) META データ - リソース表現は、フィールディング自身のように HATEOAS で駆動する必要があります。そのため、メタデータに関連リソース リンクを追加することを検討してください。
2) 同期/非同期 - API が何をしようとしているのかによって異なります。長時間実行されるプロセスを呼び出す場合は、Async API を選択するのが自然です。それ以外の場合は、Sync API を使用してください。
3) ステートフルな通信 -ステートレスであることは、REST アーキテクチャの制約の 1 つです。リクエスト間でクライアント コンテキストがサーバーに保存されることはありません。クライアントは、アプリケーションの状態を管理する責任があります。