ビジネスをインテリジェントで持続可能な企業へと変革する際に、いくつかの課題に直面する可能性があります。たとえば、クラウドベースのシステムまたはハイブリッドベースのシステムの多様なランドスケープで、アプリケーションとビジネスプロセスを統合する必要があります。また、非 SAP サプライヤのソリューションもあります。この場合、SAP プロセスから非 SAP プロセスに統合する必要があります。SAP Integration Suite を使用して、SAP を SAP プロセスに統合し、非 SAP を SAP に統合することができます。会社は、SAP Integration Suite を使用して API を商品化および管理することもできます。
アプリケーションプログラミングインタフェース (API) の説明
Objectives
- API とそのニーズについて説明します。
- API の利点を特定します。
- API の構造を分析します。
API のビジネス概要
API の概要
API は、"アプリケーションプログラミングインタフェース" の頭辞語です。これは、アプリケーション/Web サイトとユーザとの間の仲介者 (ソフトウェアによって表される) です。そのため、異なるインスタンス間の通信で情報を交換することが不可欠です。

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

REST API を最も一般的な API タイプとして使用して、REST API 機能を簡単に掘り下げます。API を使用する場合は通常、リソースを意味します。これは、通常、以下のいずれかを行うことを意味します。
- 何かを作成します (ゲストブックに新しいエントリを追加するなど)。
- API を読み込んだり、API から取得したりします (Google 検索を覚えておいてください。ここでは Web サイトの一覧を取得しようとしました)。
- 何かを更新または変更する (通常、何らかのステータスや誤植を行った場合など、変更が必要なものを作成した場合)。
- 何かを削除します。
これらのアクションを組み合わせて、CRUD と略されます。
REST API の場合、これらの動詞は CRUD 動詞に非常によく似ています。
CRUD と REST 動詞の比較
| CRUD | REST |
|---|---|
| 読込 | GET |
| 登録 | POST |
| 更新 | PUT/PATCH |
| 削除 | 削除 |
"update" には PUT と PATCH の 2 つの動詞があります。
パッチでは、参照しているリソースの一部のみが変更されます。ゲストブックのエントリーについて考えてみてください。ここでは、1 語だけ修正し、番号 42 を交換する必要があることをゲストブックに通知します。これはパッチであり、修正または変更時に行われます。一方、PUT では、ほとんど同じであっても、エラーが修正されてテキスト全体が変更されます (テキスト全体をクリアし、すべてを再度ペーストすることを検討してください)。
通常、API の仕様を確認すると、これらの動詞が下記のように表示されます (SAP BTP Integration Suite でのデプロイメント例から取得されます)。API は、必ずしもすべての動詞をサポートしているわけではありません。

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