マイクロサービス、API、イノベーション：APIの力

みなさんこんにちは！







本日、API Academyのリードアーキテクトである悪名高いMike Amundsenによるプログラミング記事の翻訳を提供したいと思います。 この比較的短いテキストで、MikeはAPIの開発に特別な注意を払う必要がある理由と、APIがどのように正しく行われるかについて知的に語っています。



APIアカデミーの教師としての時間の間に、私はたまたま世界中を旅行して素晴らしい人々に会いました。 彼らは、若いスタートアップから確立されたグローバル企業まで、さまざまな企業で素晴らしいプロジェクトに取り組んでいます。 信じられないほど、しかし私がどこにいて誰と話をしたとしても、私たちの会話には多くの一般的なアイデア、トリック、印象が浮上しました。 最も一般的な3つは、マイクロサービス、API、および革新の文化です。 これら3つはすべて、組織のデジタル変革を加速するために導入されています。



この記事は、一連の3つの出版物の2番目です。 ここでは、これら3つの強力なトレンドを背景にAPIアカデミーで教えていることについてお話します。また、あなたの会社が大きな言葉から本当のコンバージョンに移行するのに役立ついくつかのトリックについても説明します。 前回の記事では、マイクロサービスの重要性に特に注意を払い、今日できる3つのこと、1）継続的デリバリーへの移行、2）準備済みの展開の提供、3）製品が届くまでの時間を短縮するための「作業」のキューの削減に焦点を当てました市場。 これらの3つの重要な習慣は、組織がマイクロサービスの利点を最大限に活用するのに役立ちます。



APIはマルチチャネル配信を提供します



多くの企業はマイクロサービスを使用して、スケーラビリティと信頼性を確保するような方法で組織の主要な機能をカプセル化しようとしています。 マイクロサービスは、会社のITコンポーネントの重要な機能要素に対応しています。 しかし、これは戦いの半分に過ぎません。 また、これらの機会をどのように提供するかを理解する必要があります。そうすれば、彼らの助けがあれば、ビジネスが直面している現在の課題を解決するのに便利です。 これがAPIの出番です。



API-アプリケーションプログラミングインターフェイス-マシンのグラフィカルインターフェイスと同じ役割を果たします-会社の情報システムのユーザー向けです。 多くの場合、APIはさまざまな機能を一貫した手頃な価格のソリューションに混在させるために使用されます。 たとえば、会社はサービスを使用して、顧客、アカウント、および販売に関連するトランザクションを処理できます。 これらの各サービスは慎重に設計、プログラム、テストされ、その後リリースされて会社のインフラストラクチャに組み込まれました。 このサービスは、ビジネスに不可欠な機能を提供します。 ユーザーに物事の流れを紹介する新しいソリューションを作成する必要がある場合-このソリューションはさまざまなデバイスとプラットフォームで動作するはずです。 そのため、APIを最大限に使用し始めています。



ソリューションのために研ぎ澄まされた単一のAPI（たとえば、ユーザーをシステムに慣れさせるためのAPI）は、そのような慣れの段階で重要な最も重要な相互作用とタスクフローが浮かび上がるように設計できます。 ここでは、顧客、アカウント、販売に関連するさまざまな機能要素を、社内のさまざまなターゲットオーディエンス向けの安全で強力かつ手頃な価格のユーザーインターフェイスにミックスできるAPIが必要です。 たとえば、営業担当者はブラウザからログインし、オフィス管理者はPCアプリケーションから、潜在顧客はスマートフォンやタブレットからログインできます。



APIは、プログラムの要素を保持する一種の「接着剤」であると言えます。これは、内部サービスとサービスの外部コンシューマーが相互作用する中間層です。 APIは、サービスコンシューマが使用できるように主要な機能を配布するためのツールです。そのタスクは、さまざまなハードウェアプラットフォームでユーザーと対話するための重要なメカニズムを作成することです。 このような消費者には、オフィスで働く他のチーム、リモートで通信する同僚、主要なビジネスパートナー、またはクライアント側の開発または設計に関与するリモートの従業員も含まれます。



デザイン思考とAPI



ほとんどの企業は、アプリケーションのユーザーインターフェイスの開発に時間を費やすことがいかに重要かを知っています。 優れたデザインはユーザーに好まれることが知られているため、ブランドのロイヤルティを高め、新しいビジネスを促進できます。 同時に、適切に設計されていないインターフェイス設計は、顧客を困らせ、ブランドを傷つけ、収益を減らし、機会を選択する可能性があります。 同じことがAPI設計にも当てはまります。



APIが不完全な場合、開発者はそれを理解することが困難になります。このため、システムにエラーを導入し、バグの修正とインフラストラクチャの変更に不必要な費用をかける可能性があります。 ただし、APIが適切に機能していれば、従業員はAPIを効果的に使用しやすくなります。 安定したソリューションを作成するために必要な時間は短縮され、チームはクライアントや同僚を支援する新鮮で革新的なソリューションを発行するインセンティブさえ得ます。 API設計は、Amazonの最高技術責任者であるWerner Vogelsが次のように言ったほど重要な作業分野です。

APIを設計することは非常に重要なタスクであることがすぐにわかりました。

これは、パートナーをデジタルエコシステムに引き付け、ビジネスの社内の変革を簡素化するのに役立つ高品質のAPIです。 すべてを正しく行うために時間を費やす能力は、長い目で見れば、APIを完全に活用する方法を学んだ企業からたどる重要なスキルです。



基本的なAPI設計のヒント



APIを正しくすることは非常に重要です-多くの理由があります。 リリース後、APIをロールバックすることはできません。 顧客と主要なビジネス構造がAPIに依存している場合、依存関係を変更すると、システムの他の要素に損傷を与え、重要な機能を破壊し、投資と時間をゼロにできます。 APIプログラムを実装するときは、他の重要なことに留意する必要があります。 ほんの少しだけ言及します。



Canonical APIは存在しません



会社全体で標準的なAPIデザインを選択するために「事前に」試してみるのは間違いです。 企業全体にいくつかのオブジェクトとデータモデルを実装しようとしています。つまり、現在および将来、例外なく組織のすべての側面を考慮した単一のAPIを作成しようとしています。これはおそらく行き止まりです。 開発者に推奨事項を提供し、間違いを避け、同僚やパートナーの両方にアピールするすばらしいAPIを作成するためにドメインの知識を創造的に開示および適用するのに役立つ制限を示すことをお勧めします。



実装プロセス：不要なものをすべて遮断します



APIは単なるインターフェイスであり、機能するものではないため、数日ではなく数日でAPIを設計、実装、テスト、展開できる必要があります。 企業がAPIを作成するリスクを軽減し、APIを事前にテストし、リリースプロセスを自動化して、API自体のコストを削減し、作成しやすいようにする方法を知っています。



統合ではなく相互作用に焦点を当てる



成功を収めている企業が対処できるもう1つの重要な側面は、開発段階で既に設計段階にある他の要素とやり取りする機能をAPIに統合することを教える能力です。 このような組織は、APIの使用方法を説明しているため、このようなAPIは理解しやすいだけでなく、この会社の他のAPIと簡単にリンクできます。 狭く緊密な統合を設計するよりも、幅広い相互作用に焦点を合わせることが重要です。



今日できる3つのこと



このような作業は、重要な変更と同様に時間がかかります。 ただし、成功を待つのに長くはかかりません。 さまざまな企業で私が守らなければならなかった3つの対策についてお話ししますが、今日はそれを実行できます。



独自のAPIプラクティスを実践する



APIプログラムの長期的な成功の重要な要素は、テクノロジー固有のAPI設計プラクティスを開発することです。 そのようなプログラムが、ライブラリまたはプラットフォームを使用したプログラミングの最新の方法に完全に依存しないことを確認してください。 このためには、「最初のステップ-API」パラダイムに依存するのが最も便利です。



「最初のことはAPIです」ということは、最初にAPIを設計してから、その実装の詳細について考えることを意味します。 原則として、ビジネスコンポーネントは、APIの実装に使用するテクノロジー（SOAP、CRUD、REST、gRPC、GraphQL、その他の一般的なもの）に関係なく同じです。 実際、適切に設計されたプログラムを使用すると、さまざまなテクノロジースタックに関連する推奨事項をそれぞれ策定できるため、チームを支援し、可能な節約を評価し、プラットフォームの将来のバージョンで一貫した意思決定を維持できます。



APIを作成する際の低リスクを保証します



APIを高品質で設計したら、次はそれを実現します。 同時に、スケッチから始めて、プロトタイプとアセンブリパターンに進むことをお勧めします。



アウトラインAPIは、まさに「スケッチ」です。 このAPIが開発者の立場から「味と色」にどのように影響するかを印象付けるのに役立つ小さなおおよその「図面」。 APIスケッチは数日ではなく、数時間で完了する必要があります。 さらに、その基礎に基づいて、同僚や利害関係者に見せることができるプロジェクトを取得する必要があります。そのため、最初の議論と最初の修正にはほとんど費用がかかりません。 このためにApiary APIテンプレートを使用するのが好きです。 簡単なマークアップ言語を使用して、動作するAPIサーバーを数分でシミュレートできます。 特定のツールはそれほど重要ではなく、実践が重要です。 アウトラインは、安価な研究を行うのに役立ち、その後完全なAPIの準備を開始します。



プロトタイピングの際、Swagger / OpenAPIのようなツールが人気があることに気付きました。 プロトタイプは、最終製品のはるかに精巧なモデルです。 彼らは映画の風景に似ています。 よく見ると、実際のシーンが見えます！ チームは、わずか数日で詳細なプロトタイプを準備できるはずです。 このようなプロトタイプは、テスト機器、仮想化サービス、その他のプラットフォーム要素に自由に接続して、システムとの相互作用を直接観察できるようにする必要があります。 それらをテストするにはプロトタイプが必要です。 実際に機能するAPIの作成にお金を費やす必要がある前に、それらは最後の防衛線です。



これで、アセンブリ段階が完了しました。 次に、作業計画を策定し、期限を設定し、プロトタイプを製品に変え始める必要があります。 詳細を確認したり、バグを特定したりするために、スケッチとプロトタイプが必要でした。 ビルドプロセス自体はそれほど興味深いものではありません。 完成した結果を毎日表示するだけで、作業の準備が整うまで段階的にAPIを実装できます。 多くの企業は、90日以内にAPIの構築に努めています。



3つのクジラ管理API



最後に、状況を単一のAPIの設計および実装レベルよりも広く考慮する場合、組織内のAPIを操作するための実行可能なプログラムを順守し、すべてのチームに知られるAPIの開発に関する一般的な推奨事項を適用する必要があります。 明確な規制により、実装の詳細を過度に監視することなく、企業全体でAPIの開発を制御できます。

API Academyの同僚であるEric Wildeは、「APIのランドスケープを管理する」こと、つまりAPIプログラムの3つの重要な要素（プロトコル、フォーマット、および用語）​​を規制することの重要性を強調しています。



プロトコル規制は、APIリリースチームが新しいリリースを準備するときにサポートする必要があるアプリケーションレベルのプロトコルを明確に示しています。 ほとんどの企業は、すべての新しいAPIがHTTPをサポートする必要があると考えています。 MQTT、Thrift、その他のバイナリプロトコルなど、他のオプションプロトコルを示すものもあります。 ここでは、すべてのチームに事前に通知することが最も重要です。「将来、APIの相互運用性を保証したい場合は、これらのプロトコルを使用する必要があります。」 このルールを実装するには、連続配信パイプラインを使用することをお勧めします。



フォーマットの規制とは、サービス間でデータが送信されるフォーマットについて合意する必要があることを意味します。 ほとんどすべてのブラウザーは、HTML形式の応答を期待しています-そのように、APIのレベルで、どの形式でエコシステム全体とやり取りするかを決定する必要があります。 ほとんどの企業は、JSON、XML、CSVなどの単純な形式を好みますが、メッセージモデルには、特にオブジェクト名、リンク、入力フォームなどの主要なメタデータがなく、長期的なやり取りに必要です。 一方、HAL、Siren、HTTPベースのAPI向けのCollection + JSONなど、より高度な形式を使用している企業も知っています。 サービス間のバイナリインタラクションについては、多くの組織がprotobufおよび同様の形式を基盤として採用しています。 どの形式を選択するかに関係なく、アセンブリラインで確認し、規制に完全に準拠するAPIのみが本番稼働することを確認することが重要です。



3番目のAPI管理キットは用語です。 この場合、サービス間でメッセージを交換するときに使用されるデータポイントの名前とアクション識別子の制御について説明します。 用語を順守すると、組織は既存のサービスで新しいサービスが通常受け入れられることに疑いの余地はありません。 主題指向設計（DDD）のためにEric Evansが提案した「共通言語」を思い出して、最も重要なビジネスオペレーションについて話すには、選択した用語が必要であることに注意してください。 データフィールドとアクション識別子に「真新しい」名前を使用するサービスを本番環境で作成することは困難です。 それどころか、組立ラインの要素は、会社全体で受け入れられている一般的な用語に準拠しているかどうかを確認する必要があり、この用語から外れたAPIは実稼働に含まれるべきではありません。



「まず第一に-API」、「スケッチプロトタイプアセンブリ」、および「3キット管理API」という原則を学んだ後、チームは実行時の安定性を危険にさらすことなく、APIを最大限に活用できます。