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 年に導入されました。
では、どちらを使うべきでしょうか? Salesforce では、SCAPI の使用をお勧めします。
- すべての新規顧客および既存の顧客の新規プロジェクトは、SCAPI を使用する必要があります。
- 既存のプロジェクトで大規模なリファクタリング作業を行う場合は、リファクタリング作業の一環として SCAPI に移行することを強くお勧めします。
OCAPI がなくなることはありません! すでに OCAPI を使用している場合は、引き続き使用できます。Salesforce は OCAPI からの移行を強制していません。OCAPI は Shopper Login and API Access Service (SLAS) で使用できます。デベロッパーは、OCAPI での認証に SLAS の使用を開始することをお勧めします。SLAS では OCAPI と SCAPI の両方で同じ買い物客認証トークンを使用できます。
OCAPI よりも SCAPI の使用を推奨する主な理由は、機能開発とイノベーションの取り組みが SCAPI に集中している のに対し、OCAPI の更新はメンテナンス専用モードになっているためです。SCAPI を強化することで、そのパフォーマンス、機能、デベロッパーにとっての使いやすさは継続的に向上します。
新しい SCAPI エンドポイントと機能は定期的に追加されています。最近では、Page Designer をサポートする Shopper Experience API や、買い物カゴマージ機能を備えた Shopper Baskets API など、いくつかの機能が追加されています。当社ではヘッドレスコマースとコンポーザブルストアフロントを重視しているため、優れた API の必要性が高まり、SCAPI に力を注いでいます。
SCAPI を使用するその他の利点については、次のセクションで説明します。
SCAPI には、以下のセクションで示すように、さまざまな機能を備えた追加の API が用意されています。
Shopper API は、OAuth2 標準ベースの認証サービスである SLAS サービスに依存しています。これには、次のような多くの利点があります。
- パブリックおよびプライベートクライアントのユースケース (登録済みおよびゲスト) をもつ JWT ベースのトークン。
- OAuth スコープを使用して、API クライアントの許可を定義。
- 長期間にわたって簡単に更新できるリフレッシュトークン。
- 複数の ID プロバイダーのサポート。
- パスワードなしのログインのサポート。
- Account Manager に依存しない。
SLAS は OCAPI への買い物客の認証にも使用でき、移行期間中に両方の API セットを同時に使用できます。(注: OCAPI を使用した SLAS には、引き続き Account Manager 要件があります。)
Shopper Context API を使用すると、ストアフロント体験にパーソナライゼーションを簡単に取り入れることができます。Shopper Context (買い物客のコンテキスト) を使用すると、デベロッパーは買い物客のコンテキスト情報 (デバイスタイプ、店舗 ID、ソースコードなど) を設定し、それを使用してパーソナライズされたプロモーション、支払方法、配送方法を取得できます。コンテキスト情報は、顧客グループの定義に照らして評価され、顧客グループ (買い物客セグメント) が決定され、プロモーションなどの特定のセグメントに関連付けられた体験をアクティブにするために使用されます。
これは SCAPI でネイティブにサポートされており、多くのエンドポイントがコンテキストを受け入れ、パーソナライズされたレスポンスで応答します。OCAPI では、これは手動で処理する必要があります。コンテキスト情報は多くの場合、HTTP セッション内に保存され、バックエンドのカスタムフックコードで評価され、API レスポンスに影響を与えます。SCAPI を使用すると、そのようなタイプのコードをすべて排除できるため、応答時間が短縮され (カスタムコードの実行が不要)、最初から基本的なパーソナライゼーションが可能になります。
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 もそれらにアクセスできるようになります。
ヘッドレスストアフロントのデフォルト実装であるコンポーザブルストアフロントは、SCAPI のみを使用します。オープンソースの PWA Kit のすべての動作は、SCAPI の機能によって導かれます。これらは連携して動作するように作られており、当社では、コンポーザブルストアフロント向けに API をより良くするために常に API を使用および改善しています。その結果、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 の作成は、SCAPI が作成された当初から重要な部分であり、独自のコンポーザブルストアフロントが API とやり取りするための主要な方法となっています。さらに、API 用の MuleSoft コネクタも提供しており、MuleSoft 内の 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 フックのコレクションです。
- Salesforce B2C Commerce Cloud Data Connector と Shop Connector を使用すると、MuleSoft 内から SCAPI に簡単にアクセスできます。
SCAPI は B2C Commerce の開発作業の焦点となっている主要な API であるため、そのパフォーマンスはリリースのたびに改善され続けています。パフォーマンスとスケールは、当社の業務において最優先事項です。
SCAPI は、サーバー上の Web 層キャッシュを利用して、キャッシュされた項目のレスポンスタイムを改善します。このキャッシュは OCAPI によるキャッシュの実行方法とは異なり、代わりに SFRA がキャッシュに使用するのと同じサーバーレイヤーに依存します。キャッシュはエンドポイントによって制御され、OCAPI キャッシュとは異なり、キャッシュ内のパーソナライズされたレスポンスを処理します (最も頻繁に呼び出されるエンドポイントは商品用であり、多くの場合、パーソナライズされた情報が含まれています)。
商品のキャッシュでは、バリエーション、価格、画像、入手可能性の取得など、商品リクエストの展開も考慮されます。展開用に異なる構成の TTL が考慮されます。キャッシュは、レスポンスレベル全体ではなく、オブジェクトレベルでも実行されます。たとえば、最初のリクエストで 24 個の商品を取得すると各商品がキャッシュされます。後続のリクエストでさらに 24 個の商品を取得する場合に、そのうちの 8 個が最初のリクエストの 24 個の商品に含まれているとします。この場合、キャッシュからその 8 個が取得され、残りの 16 個がフェッチされます。
このレベルのキャッシングは、レスポンスタイムの全体的な改善を示しており、継続的な SCAPI キャッシング構造と機能の改善が計画されています。