アプリケーションプログラミングインタフェース (API) の説明

Objectives

After completing this lesson, you will be able to:
  • API とそのニーズについて説明します。
  • API の利点を特定します。
  • API の構造を分析します。

API のビジネス概要

ビジネスをインテリジェントで持続可能な企業へと変革する際に、いくつかの課題に直面する可能性があります。たとえば、クラウドベースのシステムまたはハイブリッドベースのシステムの多様なランドスケープで、アプリケーションとビジネスプロセスを統合する必要があります。また、非 SAP サプライヤのソリューションもあります。この場合、SAP プロセスから非 SAP プロセスに統合する必要があります。SAP Integration Suite を使用して、SAP を SAP プロセスに統合し、非 SAP を SAP に統合することができます。会社は、SAP Integration Suite を使用して API を商品化および管理することもできます。

API の概要

API は、"アプリケーションプログラミングインタフェース" の頭辞語です。これは、アプリケーション/Web サイトとユーザとの間の仲介者 (ソフトウェアによって表される) です。そのため、異なるインスタンス間の通信で情報を交換することが不可欠です。

API プロセスの視覚化。

API に気づかずに日常生活で遭遇します。たとえば、Google Search: 検索バーに何かを入力するたびに、Google のバックエンドサービスによってデータベース内のキーワードが検索され、要求の結果が Web サイトに一覧表示されます。実際には、Web サイトには API の結果が表示されます。これに対する区分は、各検索の URL です。

"SAP" を検索する場合、URL には www.google.com/search? と記載されています。q=sap

次に、これをスライスダウンしてみましょう。

ここで www.google.com、 /search はサーバアドレスであり、 /search は呼び出す機能 (この場合は Google 検索 API) を、q (クエリ) はクエリの値が渡されること (検索語句) を示します。

同じことが SAP のヘルプページ (https://help.sap.com ) にも当てはまります。検索バーに API を入力すると、URL https://help.sap.com/docs/search? が表示されます。q=api

ただし、API 呼び出しは必ずしもコンピュータによって開始される必要はありません。音声アシスタンスシステムは、API の統合と使用の一例でもあります。音声アシスタントに何かを検索するように依頼すると、実際にアシスタントにクエリが提供されます。このクエリはテキストとして保存され、クエリとして API 呼出に追加されます。その後、アシスタントは音声で API の結果を提供します。

そのため、接続されたどのデバイスを使用しても、気付かずに 1 時間に複数の API を使用しています。このため、API はオムニレスであり、ユーザーや開発者が "方法" ではなく "何を" 実行する必要があるかに集中できるため、API はこのような重要なトピックです。また、WhatsAppメッセージを受信者に送信する方法を検討したことがありますか?

そのため、その名の通り、APIは音楽の再生など、特定の機能をトリガーするために使用される多くの種類のインターフェイスの1つにすぎない。SAP がマウス/タッチスクリーンを使用してアプリケーション/Web サイト間をナビゲートするために使用する GUI (グラフィカルユーザインタフェース) など、他のタイプのインタフェースにすでに精通している可能性があります。

API の利点

API の必要性

現在、IT アーキテクチャには API が不可欠です。フロントエンドからバックエンド、インタフェース管理、ポイントツーポイント通信へのアクセスは長年にわたり IT アーキテクチャの重要な部分でしたが、API はアプリケーションや Web サイトの通信方法に革命をもたらしました。そのため、API は IT ランドスケープの構築と管理に多くのメリットをもたらしました。最も重要なもの、つまり企業が IT アーキテクチャに導入する必要がある主な理由は、以下のとおりです。

API の利点の一覧

API は、その中核で、タスクから分離された通信です。したがって、サービスが API を介して通信する場合、その API のユーザ (またはコンシューマ) は API が提供する機能に完全に焦点を当てます。ユーザーは、ジョブ自体を考慮せずに API の機能のみを使用します。フォーカスは、要求と結果 (応答) に基づいており、その他には基づきません。

API の構造

API タイプ

API の定義および実装では、さまざまなグローバル標準を使用することができます。これらのいくつかを以下に示します (ただし、最も一般的に使用される REST API)。

共通 API タイプ

REST API を最も一般的な API タイプとして使用して、REST API 機能を簡単に掘り下げます。API を使用する場合は通常、リソースを意味します。これは、通常、以下のいずれかを行うことを意味します。

  • 何かを作成します (ゲストブックに新しいエントリを追加するなど)。
  • API を読み込んだり、API から取得したりします (Google 検索を覚えておいてください。ここでは Web サイトの一覧を取得しようとしました)。
  • 何かを更新または変更する (通常、何らかのステータスや誤植を行った場合など、変更が必要なものを作成した場合)。
  • 何かを削除します。

これらのアクションを組み合わせて、CRUD と略されます。

REST API の場合、これらの動詞は CRUD 動詞に非常によく似ています。

CRUD と REST 動詞の比較

CRUDREST
読込GET
登録POST
更新PUT/PATCH
削除削除

"update" には PUT と PATCH の 2 つの動詞があります。

パッチでは、参照しているリソースの一部のみが変更されます。ゲストブックのエントリーについて考えてみてください。ここでは、1 語だけ修正し、番号 42 を交換する必要があることをゲストブックに通知します。これはパッチであり、修正または変更時に行われます。一方、PUT では、ほとんど同じであっても、エラーが修正されてテキスト全体が変更されます (テキスト全体をクリアし、すべてを再度ペーストすることを検討してください)。

通常、API の仕様を確認すると、これらの動詞が下記のように表示されます (SAP BTP Integration Suite でのデプロイメント例から取得されます)。API は、必ずしもすべての動詞をサポートしているわけではありません。

API 動詞

このレッスンの主なポイント

アプリケーションプログラミングインタフェース (API) により、アプリケーションとの通信およびアプリケーションとのデータ交換が可能になります。API を使用することで、人的労力を削減し、コストを削減し、システム統合を以前よりも大幅に高速化することができます。API の定義および実装にはいくつかの異なるタイプがありますが、最も一般的なタイプは REST API です。