API変更したら、それはコールの関連莫大なコストをもたらす可能性があり、ユーザーはすべてのコードの呼び出しをトラブルシューティングする必要がある、あなたはすべての関連部品を調整する必要があり、彼らのためにこれらの作業は、余分です。これらのハードの完了後に、また、関連するバグを見つけた場合、それはユーザーにはさらに大きな打撃です。APIは常に変化している場合、ユーザーは、現在の事業に影響を与えるであろう、プロバイダの信頼を失うことに失うことになります。
しかし、なぜ我々は、APIそれを修正する必要がありますか？より美しく見えるためのAPI？より多くの機能を提供するために？より良いパフォーマンスを提供するためには？それとも時間を変更すると思いますか？安定を使用することを好むが、とてもファンキーなAPIを見ていないユーザーのために、これは我々がAPIを改善していないという意味ではありません。APIが悪いメンテナンスコストがより多くの持ってたとき、私はそれを再構築するために私たちの時間だと思います。
あなたが戻って、再びそれを行うことができれば、とても良いAPIは、私の心はどのようにのようなものである必要がありますか？
まだ非常によく維持するかどうか、APIが優れているかどうか、単に最初のバージョンに基づいて判断を与えていないが、APIがまだ存在するかどうか、時間をかけて見てください。APIインタフェーススロットケーキ品種が、ユーザーのために良いAPIインターフェイスは、以下の点を満たしている必要があります。
- 十分に文書や他のデザインの仕事を持つなどの多くの例やコピー＆ペーストのコードを、提供し、あなたが適用されるべきである：学ぶことは簡単最少驚きを。
- 使いやすい：簡単に学習できていない複雑な手順、複雑なディテール、;柔軟なAPIがようにフィールド、カスタマイズ可能なページング、ソートやフィルタリングやソートによってことができます。完全なAPIは、所望の機能が含まれていることを意味します。
- 困難な誤用：詳細なエラーメッセージのため、一部のユーザーはAPIを経験し、マニュアルを読む必要がなく、直接使用することができます。
開発者は、要件が同じではありません。
- 読みやすい：だけもう一度コードを書くが、デバッグや修正は、コードを読み取るために必要な場合。
- 開発のしやすさ：インタフェースの最小化は、いくつかのクラスだけでなく、いくつかのクラスのメンバーとして使用することです。これは理解し、メモリを行い、デバッグはAPIを変更する方が簡単です。
上記のポイントはどのように行うには、次のいくつかの結論は以下のとおりです。
ケース設計のための1、
APIが広く使用されている場合は、APIを使用しているすべてのユーザーを理解することは不可能です。設計者が広く使われているAPIを設計したい場合、我々は、APIライブラリを設計する方法、ならびにこのようなAPIライブラリーを設計する方法を理解するために、ユーザーの視点に立つ必要があります。
2、優れたデザインのアイデアの使用
彼らは次のように設計することができた場合、設計プロセスでは、このAPIは、長生きします
- ユースケースのために設計され、ユーザからの提案を収集し、自身が使用するAPIの設計と合理的なの使いやすさを確保するために、ユーザーとしてモデル化
- 後続の要求は、拡張形式によって達成することができることを確認
- 初版の内容の新しい要件は、拡張フォームを介して行うことができますので、物事を行うには、可能な限り少しように、できるだけ少ない操作を行うには、APIの設計ミスを抑制するための効果的なプログラムであり、
- 外部リストに（セクションIを参照してください）APIを避けるために、特に、APIを使用して、ユーザーエラーを回避するために、明確なAPIドキュメントと仕様を提供し、ユーザレベルのAPIと誤用に知られています
また、以下は、いくつかの具体的な設計アプローチを示しています。
- この方法は、優れた性質であります
- この方法は、工場出荷時のコンストラクタに優れています
- 過度の継承を避けます
- 最適化されたまたは影響APIコードの再利用を避けます
- 指向プログラミング・インターフェース
- 拡張パラメータは便利でなければなりません
- どのように多くのインタフェースコンポーネント露出を決定するために合理的な位置
- 拡張ポイントを提供
3、極端なコメントを避けるために、
APIを設計する際には、特に以下の点、任意の極端な見解を避けるようにしてください：
- 素敵にする必要があります（APIは必ずしも美しい必要はありません）
- （ユーザーが適切にAPIを使用する方法を理解するために、完全にAPIを誤用するような状況を検討するAPIの設計者、困難：APIが悪用される可能性がある場合、それが悪用されます）APIを正しく使用する必要があります
- シンプルでなければなりません（私たちは常に複雑なニーズに直面して、APIを使用すると、より良いAPIを行うことができます）
- 高性能でなければなりません（パフォーマンスは他の手段によって最適化することができ、それはAPIの設計に影響を与えるべきではありません）
- 絶対に適合するものでなければならない（この記事は、互換性を確保する方法についての言及されているが、我々はまだそれを実現するために持っていますが、まれに互換性がないが許容できる遭遇）
4、有効なAPIレビュー
次のようにAPIの設計が完了した後、慎重な設計レビューを通過する必要があり、評価の焦点は次のとおりです。
- ケース駆動型を使用して、あなたは、ユースケースの正当性と完全性を保証するために、審査の前に完全なユースケースを提供する必要があります。
- 一貫性、システムの設計は、インタフェースの対称性と一致しているかどうか、インターフェイスのスタイルの他のモジュールと一致しているかどうか。
- シンプルで理解しやすいAPIを学び、私たちに多くのトラブルを与える、APIが悪用されることは容易ではなかった使いやすい、シンプルでなければなりません。
- APIを公開してもよいし、露出していなくてもよい場合は、ユーザーが本当に必要とし、それがパブリックインターフェイスになるまで、その後、彼を公開していない、できるだけAPIは後半もあります。
- 継続的な改善、簡単な方法を拡張することで、機能性と最適化を追加するためのAPIかどうかの能力をサポートしています。
テスタビリティAPIを改善するための5、
APIは、アップグレードの過程で生じない優れた互換性の問題を確実にするために、厳格な「互換性の統合テスト、」APIを介して、特に、完全なAPIをテストし、テストは実装に依存すべきではない、テストする必要があります。互換性の統合テスト、テストケースのセットグループを指し、このグループのテストケースは、APIを使用してユーザの位置に立ちます。APIのアップグレード後、その後のテストケースのセットがテストによって完全に予想に沿ったものであることができるかどうかテストし、可能な限りその互換性の問題を発見しました。
6、APIとの下位互換性を確保するために、
現在およびAPIの利用者で、またはAPIの潜在的なユーザーは、唯一の互換性これらのAPIを信頼しているため、「後方互換性」であることが熱望している各APIの設計者のために。しかし、また、重要性と複雑さを変える意味多くのレベルの下位互換性が重要、との後方互換性のさまざまなレベルがあります。
7、維持し、徐々に改善するために、
過去には、我々は常に完全に覆し、既存の「不合理」なデザインを期待して、その後、APIを再設計するために、今、「良い」アイデアに従いますが、一定期間の後に、同じような状況が発生します、我々は一度転覆する必要があります。我々は既存の設計の打倒に頼って、徐々に改善する効果的な方法を持っていない場合は、私たちだけが出発点に戻ることができ、その後、前工程を再現するAPIを再設計。同時にAPIの互換性の継続的改善に十分に確立アプローチには、それを改善するためにAPIを向上させます。
8、APIのライフサイクルを把握します
各APIは、ライフサイクルで、我々は長いライフサイクルAPIを持っている必要があり、それがライフサイクルの終わりにAPIの終焉を滑らかにします。
- 私たちはしばしば、主要なキラーの寿命が短く、間違ったAPIを使用して、ガイダンスを提供し、ユーザーは誤用を避けるように設計されている方法を教えてください
- 試用期間は、APIの安定性は強い生命力を持っているために、APIの裁判の後、開始することは不可能です
- 内部使用;二次開発、開発や臨床試験、安定性;非推奨API：APIグレードがあります。API乱用を回避しながら、我々は、APIのレベルを調整することができ、その影響力を拡大するために、だけでなく、APIのライフサイクルのよりエレガントな終わり。
APIの開発プロセスは、実際に通信するプロセスです。通信は、両方のユーザーとAPI APIデザイナーです。
図9に示すように、具体的な実施形態の数
API避けられない終焉かが変更されたとき、我々は受け入れて、この事実に直面しなければならない、いくつかの調整との互換性、APIのアプローチを確実にするための前提の下に、以下のとおりです。
- APIは新しいAPIを再確立するために、非推奨としてマーク。APIは避けられない終焉である場合、これが唯一の方法です。
- 機能の追加を実現するために追加のパラメータまたはパラメータのオプションを追加するには
- 既存のAPIは二つの部分、合理化されたコアAPI、パッケージのコアAPIによって達成過去にAPIに分割しました。あなたは、コードのストリップダウンバージョンを解決する必要がある場合は、一般的に使用されています。
- 従来に基づくカプセル化されたAPIは、より汎用性の高いパッケージやクラスを提供します
いくつかの良いAPIの例：
- API Flickrは、こちらのドキュメントである例は非常に便利提供しながら、APIテストツールを。
- メディアウィキAPI
- API eBayは、非常に詳細なドキュメントがある例。
オリジナルリンク：http://www.biaodianfu.com/how-to-design-a-good-api.html
携帯電話は、今日広く普及しているでは、携帯電話のアプリケーションは、より多くなりますが、成長のペースは非常に高速です。一般的なPCソフトウェアを使用したモバイルアプリケーション開発ソフトウェアの実装は、また、BSおよびCSモードに分かれています。主にサーバ側のインタフェースの形でCSの方法の使用は、（対話的にそこ主流データ：JSON、Webサービスなど）のデータ交換を提供し、我々は今日はインターフェースを設計する方法であると言います。
クライアントデータベースとのデータフロー通信などブリッジインターフェイスは、直接データの整合性のプログラム、安定性、信頼性と精度の効率に影響を与える、重要な役割を果たしています。クライアントの焦点は、最も直接的な経験がユーザーエクスペリエンスで、スムーズに動作させるために、簡単に美しいインターフェイスで、インターフェイスは、すべてのデータの提供、深い意味のユーザーエクスペリエンスです。
プロジェクト内の無次元、インターフェイスのデザインは、それは非常に重要です。だから私は、インターフェイスの設計方法の現在の経験をまとめたものです。
まず、設計原理
1.ニーズの深い理解に
データベース設計に加えて、ほとんどの人がニーズを理解し、第二は、インタフェース開発者は時々、データベースの設計に関与し、インターフェイスを設計した人です。「 - インターフェイス - クライアントデータベース」からのビューのレベルのポイント、インターフェースは一方のデータへのインタフェースは、データを整理し、データベースから取得する方法を検討するかを理解するために、一方では、のネクサスにおいて重要な役割を果たしています。ですから、要件を理解していない場合、あなたはクライアントにデータを整理するために、抽象オブジェクトを修正することができず、データベースのデータ構造を検証することができない需要を満たすことができます。データベースの設計者は、データの構造的要件を理解するために、インターフェイスはそれに由来する構造的要件と論理的なデータ構造を理解することが、より論理的です。
2.理解データベース構造
インターフェースは理解しているのでどのようにデータベース構造にそれを理解することは、当然のことながら、データを整理し、データベースから取得します。
3.クライアント理解プロトタイプ
実際には、あなたが設計し、インタフェースの構造を支援するために、より多くのデータを提供する必要があり、プロトタイプをご覧ください。しかし、時にはときには、プロトタイプを設計されていませんので、この規定は必ずしも必要ではありません。インターフェースデザイン仕上がっプロトタイプが出てきた場合でも、我々はまた、設計が正しいと合理的であるプロトタイプの検証インタフェースを取ることができます。
第二に、設計原理
1.良い理由
それだけで要件がインタフェースを追加していないだけでなく、機能のインターフェースがあるはずです。それぞれの新しいインターフェースは、私たちは、このインターフェイスの存在は価値の非常に重要な量であることを考慮するためにあらゆる理由を持っている必要があり、無意味なインタフェースは、メンテナンスの難しさを増加させるだけでなく、プロセスの制御のためのより重要な大幅に削減されていますインターフェイスは非常に肥大化されます。だから私は最初に置きました。
2.明確な責任
インターフェイスは、ビジネス機能で、このようなメンバーをクエリとして複数の操作を含むことができるので、単一責任の原則は、メンバーがメンバーシップのクエリシートに加えて、取得した可能性が似ているが違うとしたビジネス機能、およびデザイン・パターンのための唯一の責任がありますその他の必要な情報は、しかし、メンバーだけでなく、権利と類似した他のビジネス機能のクエリを変更していない、またやる二つのインターフェースに分割する必要があります。
3.高い凝集力と低い結合
できるだけ小さくなるように、完全なビジネス機能、及び異なるインターフェースの関連するサービスを含むようにインターフェース。メンバーまたはクエリ、時にはクエリメンバーの例としては、（例えば、ステータスなど）が変更される関連情報のメンバーのものとすることができるビジネスの完全なラインは、それがインターフェースで行われるべきであり、あってはならない時間であれば別の操作を設定するためのインタフェースが完成されます。すなわち、別のまたは複数のインターフェイスの存在を前提に変更されるべきではないインターフェイスの変化です。
4.分析の角度をクリア
明確な統一するためのインタフェースデザインの角度分析。それ以外の場合は、界面構造の混乱の原因となります。機能的な視点を設計することが必要ながら、例えば、設計の観点の役割でしばらくません。
基準に統一フォーマット
ない日付パラメータはインターフェースX、X、X日のスタイルであり、他方はXXXであるすべてのインターフェイスパラメータフォーマットとスタイルの要件ではない1つのインターフェースのパラメータは、カンマで区切られ、他方が配列され、統一します。
6.ステータスとメッセージ
必要なインタフェースのコールのステータス情報を提供します。呼び出しが成功したかどうか？これが失敗した場合は、失敗の理由があります。必要な情報をクライアントに告げなければなりません。
7.制御データボリューム
インタフェースが返すデータを過剰に含むべきではない、データの量も非常に大きいだけのデータ送信の圧力に対処していない、あまりにも複雑で、それはクライアントの応答を遅らせるためにつながります。データ・インタフェースの過度の量は、多くの場合、明確に画定されていません。
8.任意のパラメータ展開を禁止します
セクション1と同様に、それが唯一の引数の目的です。需要の変化が最初に容易にするためのパラメータを追加することによって、既存の内部インターフェースの維持が需要を満たすのではなく、するかどうかを検討すべきである前に、将来の拡張インタフェースは、追加のパラメータは、必要かつ有意義でなければならないパラメータを追加すること自由に回避することは困難ではなくなることがあり難易度より多くの変化が直接クライアント呼び出しのパラメータの変化、発生しやすいバージョンの互換性の問題につながるので、自分たちのニーズを実現します。
第三に、設計法
1.要約ビジネス
これに対して抽象オブジェクト、抽象的なより広範なビジネスでは、私はそれも比較的簡単ですと思うが、多くの場合、非常に良好ではない把握抽象スケール。
2.データ・フォーマット
データフォーマット定義されたインタフェースは完全にそうでなければ、データ変換が失敗した場合、または長さ誤差を超えて、検討されている必要があります。あなたがわからない場合は、直接文字列に最も適切です。
3.意味のある名前
インタフェースまたはパラメータ名は意味のあるべきかどうか、人々Nengkanmingbai。
要するに、インターフェースのデザインは骨の折れる作業が競合デザインがたくさんあるでしょう、ですが、個人が明確な容易にするために、そうではないだけで、クライアントのブラウザインタフェースに、粒状のデザインの方向（すなわち凝集高い）を粗い傾向があり、メンテナンスも軽く、欠点は、インタフェースの拡張を行うときは非常に柔軟ではありませんが、それは以前のように、インターフェイスを再定義することによって改善することができるが、新しいインターフェイスや二度考えるようにということです。そこに、より多くの理論的な説明がありますが、実際の作業と組み合わせる、ということを念頭におくが、ゆっくりと深くそれらの意味を理解するだろう。その理論は、実践を導く理論を検証するために練習します。
ターン：リンク
ます。https：//www.jianshu.com/p/fd0bdb5dc31dで再現