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が「優れている」かどうかについては多くの議論がありますが、それらの成功は実証されていると思います。また、それらはすべて使いやすいものです。
RESTを使用します。
RESTful Webサービスアーキテクチャは実装が簡単で、意図したとおりにHTTPの長所とセマンティクスを使用します。Web自体と同じように、リソース指向です。
アマゾンウェブサービス、グーグルおよび他の多くは、製品と相互作用するためのRESTAPIを提供しています。
RESTを使用します。
APIの標準を読むか、人気のあるものの1つからアイデアをコピーします。
ユーザーを認証するときは注意してください。
非常に簡単に始めてください。
APIを使用して（役に立たない場合でも）動作を確認するサイトを構築します。おそらく、モバイル版のサイトや、APIを徹底的に使用するように強制するものを構築することができます。