産業が成熟するにつれて、より良いエンジニアリングと利用を可能にするための標準が登場するのは必然です。
これは古くから続くことです。ローマの運河における幾何学的な複雑さ、エジプトのピラミッドにおける三角形の対称性、インドの僧院における空間的な調和であれ、標準と仕様はエンジニアが持続可能なエンジニアリングのための独自の規則を設定するのに役立ってきました。
標準は、共通のコミュニケーションと開発の枠組みを提供し、特定のニーズに基づいて適切なツールを選択する上で基礎となります。
RESTful APIの世界におけるAPI定義の標準は、OpenAPI Specification (OAS)です。
元の「Swagger Specification」に基づいているOASは、API開発において非常に注目されており、何万ものAPI開発者や利用者が採用しているのが見られます。
しかし、なぜ今なのでしょうか？ほんの数年前には、REST愛好家はRESTを定義する仕様にほとんど完全に反対していたのに、なぜ世界は突然RESTfulアーキテクチャの標準仕様を受け入れているのでしょうか？
REST APIの新時代
APIはもはやアプリケーションのバックエンドに限定されるものではありません。APIはPCの出現よりもずっと前から存在し、異なる論理ユニットを接続してきました。
かつて、APIは多くの人に使われることを意図していませんでした。APIはデータ駆動型であり、接続と通信のいくつかの特別なユースケースを解決することを目的としていました。ドキュメントは、もしあったとしても最小限であり、使用される規範はコアデータベースから直接専門用語に従っていたため、少数の人々のネットワーク外の誰も理解できませんでした。
言うまでもなく、過去のAPIはセルフサービスでの利用を意図していませんでした。
上記のことは、現代のWeb APIにはもはや当てはまりません。私たちは、APIがビジネスの構築と迅速な拡大を可能にするだけでなく、サードパーティサービスの統合と消費を通じて、共有収益と成長のための戦略的およびビジネス目標を推進する新時代にいます。前身とは異なり、REST APIの新時代はデータ駆動型ではなく、より消費者駆動型です。
真の消費者の問題を解決する適切に設計されたAPIが重要であり、Dropbox、Stripe、eBayのような企業のAPIにこの焦点が見られます。HTTP標準に基づいた再利用可能なインターフェースは、消費者の需要とセルフサービスのために構築されたデータと機能の再利用を可能にする多くの企業によって現在求められています。
OpenAPI Specification (OAS)の登場
OASは、WSDLがSOAPにとってそうであったように、RESTにとってのものです。これは、デザイナー、開発者、テスター、およびDevOpsがAPIを構築し、保守するための共通のフレームワークを提供します。この仕様は、REST APIを構築および実装するための一連のルールだと考えてください。OASは言語に依存せず、人間にも機械にも読みやすいです。これにより、ソースコードへのアクセス、追加のドキュメント、またはネットワークトラフィックの検査を必要とせずに、人々もコンピューターもサービス機能を発見し、理解することができます。
OASが消費者中心のAPI構築に役立つことはわかっていますが、開発ライフサイクルでこの仕様を最大限に活用するにはどうすればよいでしょうか？
OpenAPI駆動型API開発
定義駆動型API開発は、他のライフサイクル操作が実装される前に、APIの定義を最初に設計することを提唱します。つまり、APIのビジネスロジックを構築し始める前、エラーや欠陥がないかAPIをテストする前、または他のライフサイクル機能の前に、APIのインターフェースを設計し、APIエンドポイントが示す正確なリクエストとレスポンスを詳細に記述します。
OAS駆動型アプローチのメリット
定義駆動型アプローチは、API開発に対する消費者中心のアプローチに直接関係するいくつかの大きなメリットをもたらします。
- 開発者体験 (DX) の向上: DXとは、開発者がソフトウェアを利用したり統合したりする際に経験する可能性のある、肯定的および否定的なすべての経験の総体です。API消費における優れた開発者体験は、超競争のAPIエコシステムにおいて非常に重要です。事前にAPI消費者のニーズに集中することができます。これにより、開発者中心のアプローチを取り、開発の時間やその他の側面を急ぐ前に、最終消費者のニーズを最適に満たすことを保証できます。
- 独立性の実現: このアプローチにより、フロントエンドチームとバックエンドチーム、またはアーキテクト、テクニカルライター、QAなど、APIに取り組むさまざまなチーム間の依存関係が軽減されます。これは、APIの定義が、APIが何をすべきか、そしてそれが彼らの職務にどのように関連するかについて、さまざまなステークホルダーを調整するからです。それは、APIの意図されたサービスとその機能との間の契約として機能し、それらの間のコミュニケーションを容易にします。
- 市場投入の迅速化: 依存関係が解消されるため、異なるチームは実際にはるかに迅速かつ効率的に機能を実行できます。チーム間の引き渡しプロセスが大幅に簡素化され、APIのリリース速度がはるかに速くなります。
まとめ
現代のAPIは、もはや従来のデータ中心の世界観に準拠していません。ソフトウェアとハードウェアの両方のアプリケーションはすべて接続されており、APIはこのデジタル革命の中心にあります。これらのアプリケーションを接続するためには、実際の人間開発者がAPIが何をするかを理解する必要があります。そのため、APIの消費者中心の視点が急速に広まっています。
OpenAPI Specificationは、定義駆動型アプローチを通じて優れた開発者体験を確保しながら、顧客のニーズを解決するAPIの実現を支援します。
今のところ、API開発における定義駆動型アプローチに関するこのオンデマンドウェビナーをご覧ください。今後数か月以内に、API設計、ドキュメント、テスト、モニタリングなど、さまざまなAPIライフサイクル機能でOAS定義がどのように役立つかを詳細に説明する記事をさらに公開する予定です。