1 インターフェース名
user/user/adduser/xxx
は名前から見覚えがあり、インターフェイスを呼び出す開発者と後から引き継ぐ開発者は、インターフェイス名に基づいてインターフェイスの機能を大まかに推測できます。
2 協定
インターフェースを設計するときは、インターフェースを呼び出すためのプロトコルを HTTP プロトコル、HTTPS プロトコル、または FTP プロトコルのいずれを使用するか指定する必要があります。たとえば、言語を越えた通話では通常、WebService プロトコルが使用されます。
3 バージョン: v1
インターフェースの URL にはバージョン番号を追加する必要があります。
たとえば、Gaode マップ API:
https://webapi.amap.com/maps?v=2.0
4つのパス
インターフェースはリソースを取得するため、URL では動詞の代わりに名詞を使用するようにしてください。
/api/pruduct/v1.0/
/api/users/v1.0
5つのアクション
RESTful インターフェースの場合、インターフェースの意図を表現するアクションを指定できます。
- ポスト: 新しい
- put: 変更 (変更された完全なデータ)
- patch: 修正 (どれを修正し、どれを渡すか)
- 削除: 削除
- 取得: クエリ。
6 インターフェースパラメータの検証
入出力パラメータの検証は、プログラムを作成する際に不可欠なステップです。設計されたインターフェイスでは、最初にパラメータを検証する必要があります。たとえば、入力パラメータを空にすることが許可されるかどうか、入力パラメータの長さが予想される長さを満たしているかどうかなどです。フロントエンドまたはサードパーティの呼び出し元に例外を直接スローする代わりに、パラメーターによって返されるステータスにデフォルト値を指定したり、エラー コードや例外情報を指定したりできます。
7 スケーラビリティ
インターフェイスがログの印刷や通話情報の記録などのパブリック インターフェイスに類似している場合。現在のビジネスによって呼び出されることに加えて、他の後続のビジネスまたは機能も呼び出される場合があります。このようなインターフェイスを設計するときは、後続の機能の拡張性を考慮する必要があります。
8 インターフェースの冪等性
現在のインターフェースのビジネス機能を分析するには、ビジネスに冪等性を追加するかどうかを検討する必要があります。
具体的な実装については、インターフェイス冪等性の実装方法を参照してください。
9 スレッドプールの分離
すべてのビジネスがスレッド プールを共有し、一部のエッジ ビジネスにスレッド プールのブロックを引き起こすバグや障害が発生した場合、重要なビジネスが影響を受けます。したがって、スレッド プールが分離され、より多くのコア スレッドが重要なビジネスに割り当てられ、重要なビジネスをより適切に保護します。
10 例外とタイムアウトの処理
サードパーティのインターフェイスまたは分散リモート サービスを呼び出す場合は、例外処理、インターフェイスのタイムアウト、および再試行時間を考慮する必要があります。どのように対処するかは、実際のビジネスに応じて分析する必要があります。
11 ログ印刷
サードパーティに提供するか、サードパーティのインターフェイスを呼び出します。
通話結果の不一致が原因で問題が発生することがよくあります。通話リクエストのパラメーターまたは戻りパラメーターを出力し、問題が発生した場合に迅速にトラブルシューティングを行います。
12 インターフェースのセキュリティ
インターフェースを外部に提供する場合、インターフェースのセキュリティを確保する必要がある。
ユーザー名とパスワードの代わりにトークンメカニズムを使用します。
携帯電話番号やID番号などの個人情報をパラメータで暗号化し、機密性を解除します。