インターフェースの設計では、そのようなビジネス・ポジショニング・インタフェース、セキュリティ、インターフェイス、インターフェイスのスケーラビリティ、クロスドメイン界面の安定インタフェース、インタフェース・プロトコル・ルール、パスルールインターフェイス、インターフェイスとして考慮すべき多くの要因が存在します単一の原理は、インターフェイスは、フィルタリングおよびインターフェースの組み合わせと他の多くの要因が、この記事では、簡単にこれらの要因を分析します。
規範勧告
1.責任原則
インタフェースを設計するとき、インタフェースはインタフェースのタイプは、インタフェースがどのようなビジネス上の問題を解決する必要があることを、明確な責任である必要があります
2.団結の原則
インタフェース条件の明確な責任ではなく、3つ以上のインターフェース、シンプルであり、インタフェースだけ一つのことをしよう、と。多くの非インターフェースインターフェースの設計におけるシニアデザイナー、インターフェイスは常により多くの物事が行われていると考え、より多くの牛は非常に深刻な誤解である、交差。
3.プロトコル仕様
インタフェースを設計するとき、インターフェースプロトコルは明らかである、HTTPプロトコル、HTTPSプロトコル、またはFTPプロトコルを使用することで、特定の状況に基づくべきです。
FTPプロトコル（略してファイル転送プロトコル、FTP）、.txtなど、ファイル転送のための標準的なファイル転送プロトコルであり、.CSV FTPを使用して、他の一般的なファイル転送
一般的な安全要件のためのHTTPプロトコルは比較的低いではないか、という要件のシナリオ
HTTPS = HTTP + SSL、ビジネスシナリオの高いセキュリティ要件に適しました
4.パスのルール
取得APIは、リソースはURLようにこれまでの名詞ではなく動詞として、であるため、
/api/v1.0/pruduct/2019/api/v1.0/users/2019
5.httpリクエストメソッド
インタフェースの基本的なアクセスプロトコルは：（取得）、ポスト（新）、PUT（修正）、削除（DELETE）を取得します
取得/ユーザー：リストのすべてのユーザー
取得/ユーザー/ ID：IDに基づいてユーザを取得
ポスト/ユーザー：新しいユーザー
PUT /ユーザー/ ID：ユーザーは、ユーザーIDを更新します
/ユーザー/ IDを削除します。ユーザIDに基づいてユーザの削除
6.ドメイン名
一般的には、メインドメインとドメイン固有のサブドメイン名、メインAPIまたは長期変化するビジネスにはあまり変わらないのドメイン名は、独自のドメイン名はアドレスの特定の独自事業であります
Baiduは、例えば：
（1）プライマリドメイン名：www.baidu.com
（2）商品やサービスのカテゴリ
Baiduのライブラリます。https：//wenku.baidu.com/
Baiduは知っています。https：//zhidao.baidu.com/
Baiduの情報します。https：//zhidao.baidu.com/
（3）市場活動クラス
Baiduのパブリックます。http：//gongyi.baidu.com
百度logo：http://logo.baidu.com/
Baiduの世界ます。https：//baiduworld.baidu.com
クロスドメインを考えてみましょう7.
ドメイン名の明確なケースでは、インターフェイスのクロスドメインおよびクロスドメイン技術が使用されるべきかどうかを検討し、そうでなければなりません。
8.apiバージョン
URLのインターフェースは、v1.0を、V2.0のように、dはバージョン番号を表すバージョン番号http://api.demo.com/v{d}/、例えば、に追加する必要があります
例：製品番号2019を取得し、バージョン番号はv1.0の製品情報のバージョン番号です
/api/v1.0/Pruducts/2019
9.適度なフィルタリング情報
比較的長いデータ条件に起因するレコードの数（例えば、TBNAME SELECT * FROM）、例えばTOP、ページングなど、いくつかのフィルタリングを追加するために、適切な時間、グループ化、ソート条件WHERE
ここではいくつかの共通のパラメータがあります。
？リミット= 100：100のを返すデータ
？101 =オフセット：第101条からデータを返す開始
？ページ= 10：10ページを参照してください。
PER_PAGE = 100：データページ100
？SORTBY =名前：ソートフィールド
？注文= DESC：降順
？グループ=グループ名：グループ
？Producy_type = 1：フィルタ
10.戻りデータ・フォーマット
一般的に3つのフィールドを含む戻りデータ・フォーマット、：
（1）障害（ステータスコード、エラーコード及びエラーの説明）
（2）成功した場合（識別ID、データ・オブジェクト、ステータスコード）
11.セキュリティポリシー
インタフェース露光考慮事項、インタフェースの同時実行の考慮事項、インタフェース抗 - ***考慮事項、例えばクロスドメインのインターフェイスとして考察
12.拡張性の原則
インタフェースを設計するとき、完全に拡張インターフェースを検討します。
13.制限APIの定義
任意のAPIは、当局から、匿名と非匿名API APIに起因することができ、前者は検証が必要で認証を必要としません
14リターンコード定義されたAPI
設計APIでは、優れたリターンコードを設定するためのAPIなど、
1--ライセンスの有効期限が切れました
404--リソースが見つかりません
500--内部サーバーエラー
600--アカウントがロックされ、
2つの抗規範勧告
ビジネスシナリオがあります：同様の動作シナリオの下で、インタフェースAPIの複数の組み合わせの結果を返すために、インタフェースの必要性は、インターフェイスのデザインは、いくつかの抗規範を持っています。
1.Request
2.Responce
三つの例
ERPシステムでは、二つのインターフェースを提供する必要性、ユーザ・アクセス・インタフェース（認証が必要）、（確認なし）他のユーザ登録インターフェース：つのトラフィックが存在すると仮定する。
この記事によると、私たちは会うのビジネスニーズへのインタフェースを設計し、二つの部分をお勧めします
（A）団結のパラメータを定義します
1.統一された入力パラメータを定義します
2.統一出力パラメータを定義します。
3.統一エラーコードを定義します。
（B）界面許可カテゴリを定義
次のカテゴリの権限は、インタフェースを定義しました
（C）ユーザインタフェース
1.ユーザー登録
2.Request
3.Responce
4.code例