OCAPI の代わりに SCAPI を使用する理由

B2C Commerce には、Open Commerce API (OCAPI) と B2C Commerce API (別名 Salesforce Commerce API (SCAPI)) の 2 つの REST API 製品があります。OCAPI は 2014 年からプラットフォームに組み込まれており、B2C Commerce プラットフォームの多くのお客様に利用されています。SCAPI は、ヘッドレスコマース向けに構築された新しい API インフラストラクチャとして 2020 年に導入されました。

では、どの REST API が適しているのでしょうか? Salesforce では、SCAPI の使用をお勧めします。

すべての新規顧客と新しいプロジェクトを持つ既存の顧客は、SCAPI を使用する必要があります。
既存のプロジェクトで大規模なリファクタリング作業を行う場合は、SCAPI に移行することをお勧めします。

OCAPI がなくなることはありません! すでに OCAPI を使用している場合は、引き続き使用できます。Salesforce では、OCAPI からの移行を強制することはありません。OCAPI は Shopper Login and API Access Service (SLAS) で使用できます。デベロッパーは、OCAPI での認証に SLAS の使用を開始することをお勧めします。SLAS では OCAPI と SCAPI の両方で同じ買い物客認証トークンを使用できます。

Important

OCAPI よりも SCAPI をお勧めする主な理由は、機能開発とイノベーションのための当社の取り組みが SCAPI に焦点を当てている からです。OCAPI の更新はメンテナンス専用モードになりました。SCAPI を強化することで、そのパフォーマンス、機能、デベロッパーにとっての使いやすさは継続的に向上しています。

新しい SCAPI エンドポイントと機能は定期的に追加されています。最近では、Page Designer をサポートする Shopper Experience API や、買い物カゴマージ機能を備えた Shopper Baskets API など、いくつかの機能が追加されています。当社ではヘッドレスコマースとコンポーザブルストアフロントを重視しているため、優れた API の必要性が高まり、SCAPI に力を注いでいます。

このトピックでは、SCAPI を使用するその他の利点について説明します。

SCAPI を使用したその他の API

SCAPI には、Shopper Login and API Access Service、Shopper Context、カスタム API など、さまざまな機能を提供する追加の API が用意されています。

Shopper Login and API Access Service (SLAS)

Shopper API は、OAuth2 標準ベースの認証サービスである SLAS サービスに依存しています。SLAS には、次のような多くの利点があります。

パブリックおよびプライベートクライアントのユースケース (登録済みおよびゲスト) を含む JWT ベースのトークン
OAuth スコープを使用して、API クライアントの許可を定義。
長期間にわたって簡単に更新できるリフレッシュトークン。
複数の ID プロバイダーのサポート。
パスワードなしのログインのサポート。
Account Manager に依存しない。

また、SLAS を使用して買い物客が OCAPI に対して認証を行うことができるため、移行期間中は両方の API セットを同時に使用できます。(OCAPI を使用した SLAS には、引き続き Account Manager 要件があります。)

Shopper Context

Shopper Context API は、ストアフロントのエクスペリエンスをパーソナライズします。Shopper Context (買い物客のコンテキスト) では、買い物客のコンテキスト情報 (デバイスタイプ、店舗 ID、ソースコードなど) を設定し、その情報を使用してパーソナライズされたプロモーション、支払方法、配送方法を取得できます。コンテキスト情報は、顧客グループ定義に照らして評価され、顧客グループ (買い物客セグメント) が決定されます。次に、プロモーションなど、特定のセグメントに関連付けられている体験をアクティブにするために使用されます。

このユースケースは SCAPI でネイティブにサポートされており、多くのエンドポイントがコンテキストを受け入れ、パーソナライズされたレスポンスで応答します。OCAPI では、このユースケースは手動で処理されます。コンテキスト情報は多くの場合、HTTP セッション内に格納され、バックエンドのカスタムフックコードで評価されて API レスポンスに影響を与えます。SCAPI を使用すると、そのようなタイプのコードを排除して応答時間を改善し (カスタムコードの実行なし)、最初から基本的なパーソナライゼーションを実現できます。

カスタム API

2024 年に導入されたカスタム API は、実装の API サーフェス領域を拡張するための強力な方法です。これらは、コントローラーなどのカスタムスクリプトコードを記述し、この機能を SCAPI フレームワークの下でカスタム REST API として公開できるフレームワークを提供するため、API で時々発生するギャップを独自のコードで埋めることができます。

B2C Commerce Script API は、サーバー上の B2C Commerce プラットフォームのオブジェクトと機能へのアクセスを提供します。デベロッパーは、カートリッジ構造を使用してその場しのぎの API を公開するカスタムコードを、非常に構造化されていない形式で作成することがよくあります。カスタム API を活用することで、SCAPI が提供するすべての機能 (認証と認可、eCDN レイヤーでの OAS API コントラクトの検証、サーバー側のキャッシュ、サーキットブレーカー) を最大限に活用できます。また、カスタム API 呼び出しは、コントローラーベースの呼び出しよりも Salesforce B2C Commerce Cloud バックエンドでのリソースフットプリントが小さいため、少ないオーバーヘッドで同じ機能を利用できます。SCAPI の機能、パフォーマンス、スケールは今後も追加されていくため、カスタム API もそれにアクセスできるようになります。

コンポーザブルストアフロント (PWA Kit) による SCAPI の使用

ヘッドレスストアフロントのデフォルト実装であるコンポーザブルストアフロントは、SCAPI のみを使用します。オープンソース PWA Kit の動作は、SCAPI と連携して動作するように作られているため、SCAPI の機能に基づいて設計されています。そのため、当社は API を継続的に使用および改善し、コンポーザブルストアフロントに最適なものにすることで、すべてのユーザーにとってより優れた API を実現しています。

安定性

SCAPI は大容量を念頭に置いて構築されているため、ストアフロントの負荷が高い場合でもリクエストを処理できます。

プラットフォーム容量のレスポンス

SCAPI レスポンスには、デベロッパーが独自の容量管理を実装できるように、サーバーの容量 (0 から 100) のヘッダー情報が含まれています。この情報を得ることで、デベロッパーは、プラットフォームが特定の一時的な容量制限に達した場合にアプリケーションがどのように反応するかについて、より適切に制御できます。

レート制限とサーバー負荷管理

SCAPI は、B2C Commerce インスタンスの可用性を最大化するために、さまざまなロードシェディングとレート制限手法を使用します。レート制限はほとんどの SCAPI エンドポイントで廃止されましたが、Shopper Login (買い物客ログイン) と Omni-Channel Inventory (オムニチャネル在庫) には引き続き適用されます。他のすべてのエンドポイントは、サーバーの容量が近づくとサーバーの負荷を軽減することで保護されます。サーバーの負荷が 90% を超えると、容量が制御下に戻るまで、サーバーへのリクエストは HTTP 503 ステータスコードで拒否されます。呼び出しは、優先度の低い項目 (商品のルックアップと検索) から拒否され、トランザクションリクエスト (買い物カゴ操作) に重点が置かれます。このアプローチにより、API の利用における柔軟性が最大限に高まり、ストアフロントがプラットフォームの容量を最大限に活用できるようになります。

メンテナンスのレスポンス

SCAPI は、システムメンテナンスの場合や Business Manager でサイトがメンテナンス対象に設定されている場合に B2C Commerce プラットフォームがメンテナンスモードになると、レスポンス情報を提供します。このアプローチにより、デベロッパーは、このような状況が発生したときに、エクスペリエンスに必要なアクションを実行できます。

使いやすさ

SCAPI は、導入と使用を簡素化する機能を提供します。

標準ベース

SCAPI は API セット全体の標準に重点を置き、REST フレームワークの導入を容易にするように設計されています。SCAPI は RAML と統一された共通 API 仕様に基づいて構築されているため、API はファミリー間で一貫性を持たせることができ、新しいデベロッパーが簡単に採用できます。すべてが仕様に準拠しており、すべての API は同じ命名規則と構造を使用します。

SDK

SDK の作成は、SCAPI が作成された当初から重要な部分であり、当社独自のコンポーザブルストアフロントが API とやり取りするための主要な方法となっています。

Salesforce Commerce SDK を使用すると、Node.js ランタイム上で Salesforce B2C Commerce プラットフォームの API を簡単に操作できます。
Salesforce Commerce SDK (Isomorphic) を使用すると、Node.js ランタイム上で B2C Commerce プラットフォームの Shopper API と簡単に操作でき、ブラウザーと Node アプリケーションの両方で動作します。
Commerce SDK React は、SCAPI からデータを取得、キャッシュ、変更するための react-query フックのコレクションです。

サーバー側のキャッシュとパフォーマンス

SCAPI は B2C Commerce の開発作業の焦点となっている主要な API であるため、そのパフォーマンスはリリースのたびに改善され続けています。パフォーマンスとスケールは、当社の業務において最優先事項です。

SCAPI は、サーバー上の Web 層キャッシュを利用して、キャッシュされた項目の応答時間を改善します。SCAPI キャッシュは、SFRA がキャッシュに使用するのと同じサーバーレイヤーに依存するため、このキャッシュは OCAPI によるキャッシュの実行方法とは異なります。キャッシュはエンドポイントによって制御されます。OCAPI キャッシュとは異なり、SCAPI はキャッシュ内でパーソナライズされたレスポンスを処理します。これは、最も頻繁に呼び出されるエンドポイントは多くの場合、パーソナライズされた情報を含む商品に関するものであるためです。

商品のキャッシュでは、バリエーション、価格、画像、入手可能性の取得など、商品リクエストの展開も考慮されます。商品キャッシュでは、展開用に異なる構成の TTL も考慮されます。SCAPI は、レスポンスレベル全体ではなく、オブジェクトレベルでキャッシングを実行します。たとえば、最初のリクエストで 24 個の商品を取得すると各商品がキャッシュされます。後続のリクエストでさらに 24 個の商品を取得する場合に、そのうちの 8 個が最初のリクエストの 24 個の商品に含まれているとします。この場合、キャッシュからその 8 個が取得され、残りの 16 個がフェッチされます。

このレベルのキャッシングにより、応答時間が全体的に改善されます。SCAPI のキャッシュ構造と機能には、さらなる改善が加えられる予定です。

次のステップ

クイックスタートの手順に従って、デモサンドボックスとサンプルデータで SCAPI を試してみてください。
特定の API の詳細なユースケース情報と例については、「開発」リソースページに記載されているガイドを参照してください。
各 API エンドポイントの全機能を調べるには、参照資料セクションの仕様を参照してください。
他の Commerce API ユーザーから学ぶには、コミュニティガイドを参照してください。