質問
私は Web アプリ用の API を構築するつもりですが、人々がグッド プラクティスとして何を提案できるかに興味があります。
私はすでにバージョン管理することを計画しています (バージョン 1 はシステムの特定の側面のみを制御でき、バージョン 2 はさらに多くのことを制御できますが、これにはバージョン 1 と互換性のない認証の実行方法の変更が必要になる可能性があります)。認証は、ユーザーがログインするために使用する標準のユーザー名/パスワードとは異なります (誰かが悪意のあるツールを使用したとしても、API で許可されているものであれば、完全ななりすましにさらされることはありません)。
さらに詳しいアイデアや、特に優れた API を使用したサイトの例を持っている人はいますか?
解決
読む RESTful Webサービス この本では、実際に REST を使用する方法について概要が説明されており、すぐに理解して、自信を持ってすぐに使い始めることができます。これは、設計の選択とトレードオフについても説明しているため、既存の API を単に調べるよりも役立ちます。
他のヒント
1) バージョン番号をパラメーターとして渡すのではなく、URL に直接焼き付けます。これにより、バージョンが上がるたびに API 名前空間の構成を完全に自由に変更できるようになります。
2) URL 書き換えルール (存在する場合) をできるだけシンプル/無駄のないものに保ちます (ただし、それ以上にシンプルにすることはできません)。同時に、URL をできるだけ美しくします (ただし、それ以上ではありません)。
3) 各応答に対して見つけられる最良の HTTP ステータス コードを常に探してください (たとえば、202 と 207 を忘れないでください)。
4) ファシストパラメータ検証ロジックと有益なエラーメッセージを実装します。
5) 必要に応じて、パラメーターの代わりに HTTP 要求ヘッダーを使用します (たとえば、クライアントが応答の必要なデータ形式を指定できるようにするための Accept など)。
6) さまざまなクライアント オーディエンスが使用する URL が URL ツリーの「ルート」近くで分離されるように「名詞」を整理します (これにより、必要に応じて、それらのさまざまなオーディエンスに対して異なる認証メカニズムを強制したり、マップしたりすることが容易になります) URL ツリーの異なる部分を異なるサーバーに転送します)。
7) API と同じドメイン外で通常の Web ページを提供し、同じ認証資格情報を使用している場合は、XSRF 脆弱性を回避するために、API リクエストに X-Requested-With ヘッダーを要求します。
実証済みの API を見てみましょう。
これらの API が「良い」かどうかについては多くの議論がありますが、それらの成功は証明されており、どれも使いやすいと思います。
使用 休む.
RESTful Web サービス アーキテクチャは実装が簡単で、HTTP の長所とセマンティクスを目的に合わせて使用します。Web 自体と同じように、リソース指向です。
アマゾン ウェブ サービス, Google やその他の多くの企業は、自社の製品と対話するための REST API を提供しています。
REST を使用します。
API の標準について読むか、人気のあるものの 1 つからアイデアをコピーしてください。
ユーザーを認証するときは注意してください。
とてもとてもシンプルなことから始めましょう。
API を使用するサイトを構築し (役に立たない場合でも)、動作を確認します。おそらく、サイトのモバイル バージョンを構築するか、API を徹底的に使用することを強制するものを構築することもできます。