シリーズの前回の投稿では、Swaggerとは何か、そしてそれがどのように見えるかについて基本的なことを説明しました。今回は、Swaggerを使用するいくつかの利点について説明します。
共通言語 - 仕様として、Swaggerには従いやすく理解しやすい一連のルールがあります。これを利用することで、APIプロデューサーとコンシューマーの間で共通の基盤を持つことができます。(開発)言語に依存しないということは、アプリケーション間の相互運用が容易になることを意味します。
人間/機械に優しい - JSONとYAMLの両方をフォーマットとしてサポートしているため、Swaggerは人間と機械の両方にとって読み書きが容易です。ユーザーにとって、YAMLはJSONよりも冗長性が低いため、使いやすいフォーマットです。ユーザーは、ドキュメントのレンダリングバージョンを表示し、それと対話するために、いくつかの視覚化ツールのいずれかを使用することもできます。機械にとって、どちらも様々なライブラリを使用して解析でき、強力な統合を可能にします。
APIライフサイクル - ユーザーへのAPIの手動で管理されたドキュメントを置き換えることを考えているか、アプリケーションのAPIライフサイクル全体を管理することを考えているかに関わらず、Swaggerがお手伝いします。設計、ドキュメント作成、コード生成、テスト、API管理、モニタリング - 1つでも、複数でも、選択はあなた次第です。
開発プロセス統合 - 既存のAPIをお持ちの場合でも、新しいAPIを作成しようとしている場合でも、Swaggerはあなたのニーズに合致します。多くの言語統合のいずれかを使用して、コードから直接Swaggerドキュメントを生成するか、Swagger Editorを使用してAPIを計画および設計し、真実のソースとして使用します。必要であれば、既存のAPIから契約優先アプローチに移行することもできます。最近、Swaggerの定義とコードを緩く結合させつつも連携させる新しいアプローチを導入しました。これは、swagger-node (node.js用) または swagger-inflector (Java用) によって提供されます。
コミュニティ主導 - Swaggerが公開されて以来、ユーザーからのリクエストに影響を受けてきました。Swagger 2.0は、大手企業、小規模スタートアップ、さらには自己代表するユーザーからなる400人のオープンなグループによって推進されました。誰もが意見を表明し、問題点を提起し、仕様を前進させることができました。現在、仕様専用のgithubリポジトリがあり、ユーザーはそこで機能リクエストを開いたり、既存のリクエストにコメントしたり、一般的にSwaggerの将来に影響を与えることができます。
絶えず成長するツールセット - Swaggerをサポートするツールは、オープンソースと商用の両方で数多くあります。これらのツールは、言語統合を促進し、SwaggerをAPIライフサイクルのさまざまな部分にプラグインするために存在します。より多くのフレームワークとライフサイクルの新しい側面をカバーするために、より多くのツールが定期的に追加されています。
次回の記事では、最初のSwagger定義を使用できるようにするいくつかの方法について説明します。