プロジェクトにREST APIを追加するために使用する原則とツールについては、catの下で読んでください。
多くのAPI開発指向フレームワークがあります。 特にNodeJSでの多くが、他の言語で-十分です。 それでも、タスクがプロジェクトの既存の機能とデータを使用することである場合、ルートのアーキテクチャを変更し、すべてを別の言語またはフレームワークで書き換えることは非合理的です。 負荷の高いプロジェクトに焦点を当て、プラグインの原則に基づいて動作するZeroEngineフレームワークで記述します。 簡単に言えば、ZeroEngineの動作原理は次のように説明できます。新しい「モジュール」を既存のモジュールに組み込み、適切なタイミングで問題を制御できます。
入力をまとめます
サイトのREST APIを記述する必要があります。 このアーキテクチャにより、ルーターを実装し、既存の機能の全部または一部を使用できます。
一般的に、特にAPIを開発するときは、ロジックの法則に従い、セマンティック名、メソッド、およびパラメーターを遵守しようとします。 ZeroTechチームが採用した内部要件のサンプルリストを次に示します。
アクション/オブジェクト/識別子/メソッド
メソッドとURLは、APIメソッドによって実行される機能を明確に記述する必要があります。 厳密に言えば、APIメソッドに名前を付けるとき、リクエストメソッド（GET、POST、PUT、DELETE）は文の「動詞」であり、アドレスは一般から特定への「パス」です。
例：
- GET / images（ "get images"）-画像のリストを返します;
- POST / image-画像を公開します;
- PUT / image / 123-イメージ番号123に転送された値を「入れ」ます。
画像と画像を意図的に分離し、リクエストに応じて正確に何が来るか、つまり配列または単一のオブジェクトがすぐにわかるようにします。
セマンティックエラー
エラーメッセージについては、コードを割り当てませんが、HTTPコードの標準セットを使用します。 アプリケーション側の処理を簡素化するために、コードは応答本文に複製され、説明が追加されます。 アプリケーション開発者にすべてのエラーの詳細な説明を提供することは、デバッグ中にトラフィックを増やす価値がないと確信しています。
少ないメソッド-少ないリクエスト
コードの読みやすさと再利用に関しては、より独立したメソッドを使用することをお勧めします。 ただし、APIを開発するときは、サーバー呼び出しの数を可能な限り最小化する価値があります。 簡単に言えば、アプリケーションで一緒に表示されるデータも一緒に提供する必要があります。
2回テストしないでください
もちろん、機能テストとモジュール式テストの複製について話します。 他の場合と同様に、ツールをその目的に使用しようとします。サイトおよびルーターモジュールを単体テストでカバーし、dreddとBlueprint APIを使用してAPIをテストします。
ドキュメントによる開発
このために、Blueprint APIと養蜂場サービスを使用します。 まず、結果として得たいものを説明します。 次に、メソッドの構造、戻り値、エラーオプションなどについて考えます。 その後のみAPIを記述します。 このアプローチには多くの利点があり、API開発者はアプリケーション開発者から迅速にコメントを受け取り、二重の作業を排除できます。
バージョニング
モバイルアプリケーションに関しては、すべてのユーザーがリリース直後に新しいバージョンをインストールするわけではないことに注意してください。 したがって、インターフェイスは、古いバージョンのAPIで実行されているアプリケーションと互換性がある必要があります。 複雑なことは何もありません。アプリケーションは必要なバージョンをヘッダーで報告し、メジャーバージョンを変更して、メソッドコントローラーの古いバージョンを（古い）バージョンの番号を持つサブフォルダーに転送します。
継続的インテグレーション
TeamCityを使用していますが、クラウドサービスを含むすべてのCIサービスは、Apiaryとの統合だけでなく、単体テストとdreddテストもサポートしています。 テストが成功すると、外部のテストサイトを更新し、いくつかのメトリックを分析します。 これらのアクションにより、発生した問題をすばやく追跡し、最新のドキュメントを常に利用できるようにすることができます。
既存のプロジェクトに単体テストを実装する
すでに使用している原則を試してみてください。 そのため、ネットワークはもう1つの優れたプロジェクトになります。 それにもかかわらず、このテストがプロジェクトのために書かれていなかった場合、プロセスでユニットテストをプロジェクトに導入する際に必然的に困難に直面します。
時間をかけてコードを破棄し、ゼロから書き直してください。 プロジェクトでアーキテクチャにモジュールを実装できる場合は、カスタムテストを可能にするモジュールを作成できます。 TDDを使用して新しいモジュールを作成し、古いモジュールを徐々にテストでカバーできます。
次のようにします。モジュールのフォルダーにPHPunitとその依存関係をインストールし、モジュール自体の本体に変更されたtestRunnerを呼び出します。
$out = ''; $module = "console"; $testRunner = new PHPUnit_TextUI_TestRunner(); $testPrinter = new ZeroTech_printer($out); $testRunner->setPrinter($testPrinter); $testSuite = new PHPUnit_Framework_TestSuite(); foreach (glob(U_PATH . "/tests/*test.php") as $filename) { $testSuite->addTestFile($filename); } $testRunner->doRun($testSuite, array("verbose" => true));
実行結果は変数$ outに格納されます。 あとは、画面またはテンプレートに結果を表示するだけです。
モジュールは管理パネルからアクセスでき、次のようになります。
dreddを使用した機能テスト
上記のように、APIのプロトタイプ作成、文書化、およびテストには、apiaryサービスとそのdreddユーティリティを使用します。
- ブループリントAPI形式（ステロイドの一種のマークダウン）で機能を説明します。メソッドをグループに分け、それが必要な理由を説明します。 メソッドが受け入れるヘッダー/データ形式/パラメータ/属性、どれが必須か。 制限は何ですか。 メソッドが返すもの; エラーで答えるもの; どのフォーマットで。
- ファイルに保存し、dredd file .apibを実行します 。
- 失敗したテストを修復し、リファクタリングします。
- 養蜂場にアップロードします。
APIB構文は次のようになります。
FORMAT: 1A # Group User ## /user ### GET - [GET] + Response 200 (application/json) + Attributes + first_name: (required, string) - ( ) + last_name: (required, string) - ( ) + dob: 1988-10-01 (required, string) - + sex: 1 (required, number) - (0 - , 1 - ) + city: (required, string) - ### POST - [POST] + Request (application/json) + Attributes + first_name: (required, string) - ( ) + last_name: (required, string) - ( ) + dob: 1988-10-01 (required, string) - + sex: 1 (required, number) - (0 - , 1 - ) + city: (required, string) - + Response 201 { message: “Successfully created”, id: 123 }
Apiaryは、これらすべてをモックサーバーとの便利なインターフェイスに変換します。 アプリケーション開発者は、ライブAPIがまだ作成されていないか、正しく動作しない場合でも使用できます。 モックサーバーをサンドボックスとして使用することもできます。
さらに、たとえば継続的な統合インターフェイスがない場合は、dreddユーティリティを使用してテスト履歴を見ることができます。
おわりに
結論として、開発で使用するツールやテクニックはそれほど重要ではないという事実に再び焦点を当てたいと思います。主なことは、それらの使用目的が理解されているということです。 プログラマーとしての私たちの仕事は、プログラムが必要とすることを可能な限り正確かつ迅速に実行することです。 それ以外はすべてセカンダリです。