API(Application Programming Interface)とは?

Michael Chen |シニア・ライター| 2025年2月24日

この記事の内容

「API」という用語は、アプリケーション・プログラミング・インターフェースを表します。APIはアプリケーション間のブリッジとして機能し、アプリケーション間の通信およびデータの共有を可能にします。たとえば、マーケティングチームが複数のソーシャルメディアアカウントを管理するためのダッシュボードは、各SNSプラットフォームと接続し、必要なデータを取得・表示するためにAPIを利用しています。

一般的なインターネットユーザーも、意識しないまま日常的にAPIの恩恵を受けています。たとえば、天気予報サイトの公開データを商用アプリに連携して嵐の接近を通知したり、開発者がGoogle Maps APIを利用して地図や位置情報サービスを自社サイトに埋め込んだりするのがその例です。小売業者は、PayPalやStripeなどのAPIを利用した支払ゲートウェイを使用して、顧客との財務取引を安全に処理します。

APIとは

API (アプリケーション・プログラミング・インタフェース)は、アプリケーションがデータを交換したり、アクションを実行したり、適切にドキュメント化された方法で対話できるようにする一連のルールおよびプロトコルです。たとえば、天候更新のためにリクエストが行われた場合、APIはリクエストを処理し、必要なアクションを実行し、通常はJSONやXMLで定義されたような標準形式でレスポンスを返します。

主なポイント

  • APIはソフトウェア同士の仲介役であり、どのようにデータや機能をリクエスト・受信するかを定義します。
  • APIは、情報を接続および共有する最新のソフトウェア・アプリケーションを構築するために不可欠です。
  • APIは、クラウド・サービスをオンプレミス・ソフトウェアと統合および共有できるようにすることで、クラウド・サービスの使用を可能にするために重要な役割を果たします。

APIの説明

APIを使用すると、開発者は、構築しているアプリケーションからソフトウェア・プラットフォームとサービスにネイティブにアクセスできます。APIを使用しない場合は、ユーザーが天気を確認したり、ソーシャル・メディア・サイトのコメントに応答したりするたびに、データを1つのアプリケーションから手動でエクスポートし、準備して変換してから、別のアプリケーションに手動でインポートする必要があります。

簡単に言えば、次の3つのパーティが交換プロセスに関与しています。

  • クライアント: 要求を行うパーティ
  • サーバー: 要求を履行するパーティ
  • API: 適切に文書化された予測可能な方法で両者を接続する仲介業者

レストランの例で考えてみましょう。もしお客がキッチンに押しかけて、自分の料理を直接注文しようとしたら、大混乱になります。このシナリオでは、APIは、キッチン (サーバー・アプリケーション) が提供できるすべての料理 (サービス) が記載されたメニュー (ドキュメント) を提供し、そこにはお客（クライアント）がどんな情報を、どのような形式で出せばよいかが明確に記載されています。

APIはウェイターのような存在で、注文を正確かつ標準化された方法で伝え、結果を確実に受け取って届けてくれるのです。

APIの仕組み

APIは、ソフトウェア・コンポーネントの対話方法を指定することで機能するため、開発者は、すべてをゼロから構築する必要なく、異なるシステムを統合し、データや機能を共有できるため、時間とリソースを節約できます。APIは通常、通信に使用する必要があるメソッドとプロトコル、および交換可能なデータ形式を定義します。

APIは、次のような詳細を提供することで、アプリケーションの対話方法を定義します。

  • エンドポイント。データおよびリクエストの送信先を定義する特定のURL。
  • メソッド。データを取得するGET、データを送信するPOST、データを更新するPUT、データを削除するDELETEなどの手順。
  • パラメータ。天気データの場所やソーシャルメディアのログイン資格情報など、リクエストに必要な固有の詳細。
  • 応答。アプリケーションによって返されたデータの形式(JSONやXMLなど)。

データをリクエストするクライアント・アプリケーションの開発者は、APIコールを行うためのコードを記述します。このコードは、次を指定します。

  • APIエンドポイントURL
  • HTTPメソッド
  • 必要なパラメータ

アプリケーションは、受信リクエストを管理するサーバー・アプリケーションのAPIゲートウェイにリクエストを送信します。APIゲートウェイは、ターゲット・アプリケーション内の適切なサービスにリクエストをルーティングします。サービスはリクエストを処理し、データを取得するか、別の必要なアクションを実行します。

次に、ターゲット・サービスは、API定義に従ってレスポンス・データを準備し、それをAPIゲートウェイを介してリクエスト元のアプリケーションに送信します。リクエスト元のアプリケーションは、データを受信して解析し、予想される結果をエンド・ユーザーに配信します。

APIが重要な理由

開発者が他のアプリケーションやサービスのデータや機能にアクセスするための標準化された方法を提供するため、APIを使用すると、企業は一般的なホイールを再作成する必要がなくなります。それは時間とお金を節約する。また、標準化は、既存のシステムの運用を中断することなく、新しい機能やサービスをモジュール形式で追加できるようにすることで、イノベーションとスケーラビリティの両方を促進します。

ビジネス・レベルでは、APIは、ソフトウェアが他のソフトウェアと直接対話できるようにすることで、反復的なタスクやプロセスを自動化できるという点で重要です。ほとんどの企業が、より高いレベルのタスクのために従業員を解放するための自動化の追加に取り組んでいることを考えると、APIが手動のワークロードを減らし、運用効率を向上させることが大きなメリットです。クラウド・サービスの使用を増やすことを検討している組織も、APIに大きく依存しています。

APIコンポーネント

APIコンポーネントは連携して動作し、様々なソフトウェア・システムがデータと機能を通信および交換できるようにします。これらのコンポーネントの理解は、APIをソフトウェアに正常に統合するために不可欠です。APIコンポーネントには次のものがあります。

  • API仕様では、APIの動作と、APIとの正確な対話方法について構造化された説明を提供します。
  • APIデザイナは、開発者がAPIを作成するのに役立つユーティリティです。APIデザイナは、開発環境用のプラグインや非常に専門的なツールと同じくらい簡単です。目標は、APIを検証および書式設定するためのルールを組み込み、時間と増大を節約することです。
  • APIポータルは、開発者が公開されているAPIおよびperuse仕様を見つけて共有し、APIがそれらに役立つかどうか、およびその使用方法を理解するためのものです。パブリックAPIのポータルは、多くの場合、法的条件などのサポート資料のWebサイトに組み込まれています。
  • APIバックエンドは、APIコールをクライアントのアクションに変換するソフトウェアです。
  • APIゲートウェイは、APIのURLを提供し、そのAPIの使用を管理するルールを適用して、関連するバックエンドにAPIコールを指示します。通常、ゲートウェイは、API仕様と適用する必要があるルールの詳細の両方を認識します。ルールは、認証と認可、証明書管理、レート制限とスロットル、ペイロード検査と検証、ヘッダーまたはペイロード・コンテンツに基づくインテリジェント・ルーティングなどに対応できます。

APIには、レート制限、エラー処理および開発者向けのドキュメントが含まれる場合もあります。確かなAPIの作成には、アーキテクチャ・スタイルから設計ツールまで、一連の意思決定が伴います。これは、クラウドネイティブの未来を見据えた組織にとって貴重なスキルです。

APIの利点

APIを使用することで、開発者は分散アプリケーション(スマートフォン・アプリケーションなど)をソーシャル・メディアのWebサイトに接続したり、給与計算システムをビジネス銀行口座に接続できます。APIにより、小規模、個人、コネクテッド・サービスから便利なアプリケーションを構築できるため、堅牢性とスケーラビリティのメリットが得られます。

1つのサービスが中断した場合、ほとんどのアプリは継続できます。その他の利点は次のとおりです。

  • アジリティ。APIを使用すると、開発者は、解決する必要がある問題ごとに最適なテクノロジを選択できます。
  • 開発を高速化。APIを使用すると、開発者はすべてをゼロから構築するのではなく、既存の機能をプラグインできます。
  • イノベーション。APIは、開発者が新しいサービスを発見し、多額の投資なしで試すことができるようにすることで、コラボレーションと実験を促進します。
  • 制御性。APIには厳格な認可制御が備わっており、アプリケーションがアクセスできるデータやアクションを詳細に制限できます。
  • スケーラビリティ。APIにより、アプリケーションは、他のサービスへのアウトソーシング・タスクによって需要の増加に対応できます。たとえば、小規模な小売業者は、独自の支払処理システムを維持するかわりに、StripeやPayPalなどの支払APIを選択できます。これにより、複雑なタスクがオフロードされます。現在、営業担当者はコア・ビジネスの成長に注力しながら、支払処理をエキスパートに任せ、顧客の信頼性を高めることができます。

APIの課題

APIのすべての上面において、APIコールを使用するアプリケーションを設計する場合、および独自のAPIを構築する場合に考慮する必要がある複雑さ、コストおよびセキュリティに関する課題があります。複数のAPIに依存するソフトウェアは、特にAPIプロバイダが頻繁に更新または変更を行うと、管理およびメンテナンスが困難になる場合があります。

取り組むべき具体的な課題は次のとおりです。

  • APIの選択。膨大な数のAPIが使用可能なため、最適なAPIを選択することは困難なタスクになる可能性があります。実際、完全なAPIは1つではなく、複数のソースからのデータと機能をまとめる必要がある場合があります。
  • コスト。多くのAPIは自由に使用できますが、コールと機能の制限に注意してください。アプリケーションおよびオーディエンスによっては、特定の機能または容量に対して有料サブスクリプションが必要な場合があります。定額または使用量ベースの料金を支払いますか?API接続を維持するための継続的なコストも、アーキテクチャ設計の決定に反映させる必要があります。

    多数のAPIを使用する場合、または少数のAPIに大きなボリュームがある場合は、API使用計画を検索して、コストを管理できます。
  • 統合の複雑さ。適切なAPIを見つけた後でも、それをアプリケーションと統合することは複雑な作業になる可能性があります。異なるプロバイダのAPIには、異なるプロトコル、データ形式および認証メカニズムがあります。ギャップを埋めるには、かなりの開発作業が必要になる場合があります。
  • パフォーマンス。APIのパフォーマンスは、アプリケーションの使用に不満を抱く可能性があります。APIでは、応答時間が遅くなり、データ処理が遅くなるレイテンシが発生する可能性があります。従業員または顧客はAPIプロバイダを非難しないことに注意してください。アプリケーションでの会社名です。
  • セキュリティ。APIの発見を容易にすることで、誤用リスクが高まるため、企業はセキュリティに注意する必要があります。幸いなことに、適切なツールを使用すると、安全なAPIを作成することは合理的に簡単です。認証メカニズム(APIキー、トークン、その他の資格証明など)は、認可されたアプリケーションのみがシステムにアクセスできるようにします。APIのデータ暗号化標準を確認してください。さらに、適切に設計されたAPIは、そのバックエンドの実装方法を隠蔽するため、チームはクライアントに悪影響を及ぼすことなく変更を加えることができます。
  • ベンダー・ロックイン。アプリケーションにとって重要な機能に特定のAPIプロバイダを多用することで、そのエコシステムにロックインできます。将来、APIプロバイダを切り替える場合は、コストがかかり、中断を伴う操作になる可能性があります。
  • バージョニングの問題。ほとんどのソフトウェアと同様に、APIは静的ではありません。新しい機能を追加し、セキュリティと技術的な変更に対処するために進化しています。新しいバージョンでは、アプリケーションを中断するコード変更が導入される場合があります。また、機能不全がなくても、さまざまなAPIバージョンや統合の記録を保持することは大きな負担になる可能性があります。

関連して、すべてのAPI開発者が、開発者がAPIを使用し統合するために不可欠な明確で包括的なドキュメントを提供しているわけではありません。そのため、プロバイダーパートナーを慎重に選択してください。

一般的なAPIミス

APIの開発を検討している人には、特に仕様の選択や需要の過小評価に関して、いくつかの目標があります。優れたAPI設計の原則は、バックエンドの実装方法の変更からコンシューマを抽象化して保護することです。API設計には、基礎となるデータ・ストレージが直接反映されるため、内部データ構造が変更されると、APIが影響を受けるため、APIクライアントが中断する可能性があります。

回避するその他のミスは、次のとおりです。

ドキュメントが悪い。APIの成功には、明確で詳細なドキュメントが不可欠です。たとえば、日付を記述する場合は、書式をクリアする必要があります。ヨーロッパでは通常、日付は日、月、年として表され、北米では月、日、年として表されます。そのような詳細を明確にしないと、データ品質の問題が発生し、最悪の場合、APIがアプリケーションを破壊する可能性があります。

本番データ量を考慮しない。APIの開発中、テストでは比較的小さなデータセットが使用されます。本番環境では、データ量がはるかに大きくなることが多いため、APIコールは1回のリクエストで大量のデータを通信しようとします。これにより、クライアントとバックエンド間のネットワークに応じて、様々な問題が発生する可能性があります。最悪の場合、リクエストによってAPIバックエンドに過剰な需要が発生し、APIコールが失敗する可能性があります。

APIゲートウェイのポリシーを設定する場合も、ミスが発生する可能性があります。これらのエラーには通常、十分なセキュリティーが提供されないため、悪意のある攻撃者はデータを変更したり不適切にアクセスしたり、ネットワークを攻撃する方法としてAPIを使用したりする可能性があります。これらの種類の問題はOWASP Foundationによって分析および収集されており、最も一般的なミスは「上位10 APIのセキュリティ・リスク」リストで報告されます。

APIゲートウェイとAPIバックエンドのロールを混乱させることは、もう1つの一般的な間違いです。どちらの機能も、受信時にAPIを処理する必要があり、2つの要素を簡単に混在させることができます。ただし、ゲートウェイのジョブは、リクエストを適切な場所にすばやくスクリーニングおよびルーティングすることです。APIバックエンドは、ビジネス・ロジックを提供しているため、各リクエストの処理に時間がかかります。

APIコールとAPIバックエンドの関係は1対1ではないことに注意してください。

APIのタイプ

APIには主に4つのタイプがあります。どちらを選択するかは、ユース・ケースによって異なります。モデルに定着する前に、アプリケーションの短期および長期の計画を検討してください。異なるAPIでのスワッピングは可能ですが、コストと複雑さが増します。

  • パブリックAPIは、だれでもクライアント・アプリケーションからサーバーのデータまたはその他のサービスにアクセスするために使用できます。パブリックAPIの一般的な用途には、トラフィックや気象データの取得、サードパーティのログイン・プロセスの管理などがあります。パブリックAPIは、通常、すべてのアプリケーションでサービスを使用できるようにすることを目的としています。このアクセスは、現在の時刻を取得するといった簡単な操作から、気象レーダー画像の取得や、ポイントAからポイントBまでの詳細な経路リストの取得といった複雑な操作まで、さまざまなものがあります。パブリックAPIは広く使用される傾向があるため、アプリケーションの機能を壊さないように、絶対に必要な場合を除き、変更しないよう十分に注意してください。
  • プライベートAPIは、内部使用のみを目的として開発されており、広く公開されていません。通常、プライベートAPIを使用すると、ベンダーのアプリケーションは、そのベンダーのサーバーと通信できます。たとえば、電話のバンキング・アプリケーションは、プライベートAPIを使用して、特定の銀行の一意のサービスにアクセスします。
  • パートナーAPIは、特定の組織間で使用するために開発されています。APIの詳細は、限られたパートナー・セットに開示されています。たとえば、クラウド・データベース・プラットフォームは、一定数の分析プロバイダとの提携に同意する場合があります。これにより、パートナーAPIが効率的に分析プラットフォームとデータベースを接続できるようになります。
  • コンポジットAPIは、特定の関数に対して連鎖され、パブリック、プライベートおよびパートナAPIの組合せである場合があります。パブリックAPIとプライベートAPIを使用した連鎖APIの例は、天気アプリとフィットネス・トラッカー・アプリの統合です。天気アプリの公開APIは、温度や湿度などのデータをフィットネス・トラッカー・アプリに提供します。そのプライベートAPIは、所有者のペースと移動距離のデータを取得し、環境要因と組み合わせて消費カロリーを計算します。

APIの例

ほとんどの人は、天候や場所など、コンシューマAPIに精通しています。しかし、クラウド・サービスからデータベース、堅牢なビジネス・アプリケーションまで、企業が機能を利用できるようにする高度なAPIが揃っています。

たとえば、Oracleはサービス全体で幅広いAPIを提供しています。Oracle Cloud Infrastructure(OCI)を使用している企業は、APIを利用して、サブネット、セキュリティ・リスト、ルート表の作成、構成、管理など、仮想ネットワークをプログラムで管理できます。コンピュートAPIにより、管理者はOCIでコンピュート・インスタンスを起動、停止、再起動および構成できます。その他のAPIは、ITチームとオブジェクト・ストレージ、アイデンティティおよびアクセス管理機能を接続します。

革新的なスタートアップ企業もAPIを使用しています。例えば、Inworld.aiは、オンラインロールプレイングゲーム向けにAI駆動型のバーチャルキャラクターを提供しています。APIを使用することで、開発者はプレイヤーと現実的で没入感のある方法で相互作用する非プレイヤーキャラクター（NPC）を作成できます。APIは、ゲームデザイナーがキャラクターの属性、性格、行動を指定できるようにし、これによりNPCをカスタマイズしてゲームに深みと多様性をもたらすことができます。バーチャルキャラクターは、テキストや音声の入力を理解し、APIを介して応答することができます。

ドミノ・ピザがAPIを活用して音声アシスタントと連携し、顧客がデバイスに触れることなくピザを注文できる仕組みから、ウーバーがAPIを利用してリアルタイムデータに接続し、需要と交通状況に応じて配車料金を動的に調整する仕組みまで、この技術は現在、真のイノベーションを推進しています。

APIのユースケース

一般の人にとって、ソーシャルメディアの統合や支払い処理を可能にするAPIは馴染み深いものとなるでしょう。多くのWebサイトやアプリケーションは、コンテンツの共有などの一般的なソーシャル・メディア機能を有効にするためにAPIを使用し、eコマース・プラットフォームはAPIを使用してStripeやPayPalなどの支払ゲートウェイに接続します。

しかし、APIが私たちの日常生活を便利にする方法はそれだけではありません。これらのサービスは、地図APIを利用して顧客の自宅や目的地の位置を特定するライドシェアリングやフードデリバリーサービスを提供するアプリが利用するジオロケーション機能を可能にします。

ビジネス面では、APIのユース・ケースとして、財務やカスタマー・サービス機能に使用するアプリケーションなど、チームがクラウド・リソースと対話できることが挙げられます。APIは、IoTデバイスとその制御システム間の電力通信およびデータ交換でもあります。

照明や温度が自動的に調整されるスマートオフィスにもAPIが活用されています。

APIプロトコル

APIを開発者に公開するためのプロトコル(アーキテクチャ・スタイル)がいくつかあります。これらのアプローチは、開発者がAPIのセットがどのように機能するかを予測し、自社のプログラムからAPIにアクセスする際の一般的なメカニズムを理解できるようにします。

一般的なアーキテクチャ・スタイルは次のとおりです。

  • 表現状態転送(REST)
    これは、Web上のリソースおよびサービスにアクセスするための最も一般的なアーキテクチャです。多くの環境では、クライアントはサーバーに対して状態を変更するプロセスを経由します。たとえば、銀行残高を知りたい場合は、未認証状態から認証済状態に移行する必要があります。次に、サーバーおよびクライアントは、その認証状態を確立後に維持します。対照的に、REST APIはステートレスです。開発者がREST APIを使用して銀行残高を確認する場合、リクエストには、リクエストを行うユーザーを認証するための十分な情報を含める必要があります。要求が処理されると、状態情報は保持されません。ユーザーが別の同様のリクエストを実行する場合は、再度リクエストに認証情報を提供する必要があります。REST APIの利点の1つは、サーバーがクライアントの状態を追跡する必要がなく、サーバーのアーキテクチャを大幅に簡素化できることです。
  • リモート・プロシージャ・コール(RPC)
    従来のアプリケーションでは、プロシージャ・コール(関数コールとも呼ばれる)を使用して、アプリケーションが実行されているコンピュータのデバイスおよびサービスにアクセスします。ファイルを開いたり読み込んだり、コンピュータのディスプレイや他のデバイスに書き込んだりすることは、プロシージャ呼び出しを通じて処理される機能です。このようにして、オペレーティングシステムは、アプリケーションとコンピュータの実際のハードウェアとの間に抽象化の層を提供します。アプリケーション・プログラマは、コンピュータの表示について何も知る必要はなく、ただプロシージャ・コールを使用します。同様に、プロシージャ・コールによって、アプリケーションがネットワーク上のリソースを使用できるようになります。ユーザーのファイルは、ローカル・コンピュータではなく、ネットワーク・サーバー上にある可能性があります。リモート・プロシージャ・コールにより、ジョブが完了します。アプリケーションは、使用するリソースがローカルかリモートかを知りません。オペレーティング・システムはそれを特定し、リクエストを実行するための適切なステップを実行します。一般に、RPCは任意の形式を使用して関数にアクセスできます。通常、呼び出しの動作方法に関する規則は、オペレーティングシステムのドメインです。

    オペレーティング・システム・コールは、1つのタイプのRPCにすぎません。他の種類を開発することで、ほぼ何でも行うことが可能です。たとえば、企業は、従業員の勤務時間を追跡するために独自のアプリケーションを作成できます。開発者は、基本的なネットワーキング機能を使用して、モバイル・アプリがチェックインやチェックアウトを中央サーバーに報告する手順を作成できます。RESTなどの標準アーキテクチャを使用すると、他の開発者がRPCの動作を理解しやすくなるため、様々なライブラリによってこの開発が容易になります。
  • 簡易オブジェクト・アクセス・プロトコル(SOAP)
    RESTと同様に、SOAPはインターネット上のサービスにアクセスする方法を提供します。XMLを使用して、リクエストのフォーマット方法を定義し、様々なトランスポート・プロトコルで実行できます。つまり、ベンダーに依存しません。SOAPは、HTTPがトランスポート・レイヤーとして機能するWebサービスへのアクセスに最もよく使用されます。アプリケーションが製品の説明を取得する場合は、適切なXMLドキュメントを作成し、その製品について知っているWebサーバーに送信します。Webサーバーは、要求された製品情報を含む独自の XMLドキュメントを送信します。SOAPはオブジェクトを取得することを目的としているため、アクションはGET、POST、PUTおよびDELETEに制限され、プロトコルの動詞構造が非常にシンプルになります。

API統合

API統合はアプリケーションを接続し、データと機能の交換を可能にします。統合を、オープンな双方向のコミュニケーションを可能にする電話回線のようなものと考えてみてください。

API統合には、次の3つの要素が関わります。

API自体には、アプリケーションの通信方法を示すルールおよび仕様が用意されています。APIは、交換可能なデータ、そのフォーマット方法、およびトリガーされるアクションを定義します。

サーバー・アプリケーションは、APIを介してその機能またはデータを公開します。たとえば、クラウド・サービスは、ITチームが新しいインスタンスを迅速に立ち上げたり、ユーザー数を増やしたりできるようにします。

クライアント・アプリケーションは、APIを使用してサーバー・アプリケーションからのデータまたは機能をリクエストします。たとえば、ライドシェア・アプリは、天気サービスのAPIを使用して、雨が降ったり、特定の温度しきい値を超えたり、下回ったときに価格を調整します。

実際のプロセスには、クライアント・アプリケーションの開発者が適切なAPIを選択することから始まる、いくつかのステップが含まれます。クライアントは、APIキー、トークンまたはその他の資格証明を使用して、目的のAPIで認証し、特定のデータまたはアクションにアクセスするための認可を取得します。次に、必要なデータまたはアクションを正確にリクエストするサーバーのAPIへのリクエストまたはコールを行います。

サービング・アプリケーションはリクエストを処理し、認可されている場合は、アクションを実行するか、データを取得して、APIを介してJSONやXMLなどの構造化された形式でクライアントに返送します。

APIとデジタル・トランスフォーメーション

APIとデジタル・トランスフォーメーションの本質はクラウド活用にあり、その中核を担うのがAPIです。APIはクラウドネイティブなアーキテクチャにおいて不可欠な存在です。APIにより、クラウド内のサービスとシステムを統合でき、企業はレガシー・アプリケーションを新しいクラウド・サービスに接続できるため、業務を中断することなく、デジタル未来への段階的な移行が可能になります。また、APIを使用することで、企業は市場の変化や機会に迅速に対応できます。たとえば、決済ゲートウェイ、SNS連携、分析ツールなどの最新サービスをアプリケーションに直接組み込むことも可能です。

もう1つの変革的でAPI主導型のテクノロジは、マイクロサービスであり、独立したサービスと機能を好む最新のアプリケーション開発に対するアーキテクチャ・アプローチです。マイクロサービス・アーキテクチャでは、アプリケーションは、単一のタスクを効率的に実行する、含まれている構成要素に分割されます。マイクロサービスは、APIを使用して他のアプリケーションやサービスと通信します。アプリケーションには、わずか数個のマイクロサービスがあるか、数百または数千の可動部分で構成されている可能性があります。マイクロサービスベースのアプリケーションは、個々の要素が独立しているため、より迅速に拡張できます。これにより、レガシー・ソフトウェア開発で使用されるモノリシック・アーキテクチャによって妨げられる可能性のあるデジタル・トランスフォーメーション・イニシアチブに必要な俊敏性と柔軟性が得られます。

マイクロサービスを導入するクラウドネイティブ企業は、迅速に移行して新しい機会を獲得し、自動化を導入することができます。APIはその戦略を支えています。

Oracleがどのように役立つか

Oracle Cloud Infrastructure(OCI)は、APIのライフサイクルを管理する包括的なサービス・セットを提供しています。あらかじめ組み込まれているツールにより、開発者チームはコラボレーションしながら、APIのプロトタイプ作成やテスト、検証を簡単に行うことが可能です。Oracle Cloud Infrastructure API Gatewayは、APIおよびSOAベースのシステムに対して統合、高速化、ガバナンス、およびセキュリティを提供し、チームがWeb APIはセキュアに管理および配信できるようにします。さらに、利用プランとサブスクリプションにより、APIオペレータはAPIを監視して収益化することもできます。

開発チームがAPIの仕組みを理解すると、顧客や従業員が毎日使用する多くのアプリケーションやサービスを強化する隠れたつながりについてのインサイトを得ることができます。現在、開発者は、すべてをゼロから構築するのではなく、APIを通じて公開されているデータや機能を活用することで、アプリケーションをより迅速かつ適切に構築できるようになりました。

財務アプリケーションは、APIの主要な、そして要求の厳しいユースケースです。CIOは、CFOが従業員と顧客の両方を満足させるシステムを提供できるように支援します。コア財務プロセスの合理化に役立つその他の方法を次に示します。

APIに関するFAQ

4つのタイプのAPIは何ですか。

APIには4つの種類があります。公開API（誰でも使用可能です）、プライベートAPI（組織内で開発されたもの）、パートナーAPI（関連する組織のソフトウェア間で動作するように開発されたもの）、および複合API（複数の種類のAPIを組み合わせて使用するもの）です。

実際のAPIの例を教えてください。

パブリックAPIプロバイダーの良い例はNASAで、研究データ、画像、イベント追跡情報を共有するAPIを提供しています。これらのAPIにより、開発者は、火星ローバーの更新や火山噴火などのNASAが追跡する自然イベントの詳細など、選択したNASAデータのフィードを取得し、独自のアプリケーションに統合することができます。たとえば、ある天気予報アプリでは「火星からのライブ映像」という特集セクションを設け、NASAのAPIから取得した探査機の最新データをユーザーに提供することも可能です。

APIの作成は簡単ですか?

特に経験豊富な開発者にとっては、APIの作成は簡単なプロセスになる可能性があります。APIはほぼすべてのプログラミング言語でコーディングでき、RESTなどの既存のアーキテクチャでは、作業するためのガイドラインが確立されています。API開発を学ぶ簡単な方法は、パブリック・オープン・ソースAPIをリバース・エンジニアリングして、アーキテクトがどのようにAPIを作成したかを確認することです。

REST APIの概要

RESTは、RESTfulとも呼ばれ、「表現状態転送」を表し、Webサービスの開発に使用される標準プロトコルです。RESTには、様々なアプリケーションがスケーラブルで効率的な方法でインターネットを介して通信できるようにするための一連のルールおよびガイドラインが用意されています。RESTは、クライアントとサーバー間のステートフルな関係を確立することなく、アプリケーションがHTML、XLT、Python、JSON、PHPまたはプレーン・テキストを使用してHTTPを介してリクエスト(通常はGET、PUT、POSTおよびDELETE)を行う方法を定義します。