GraphQL 顧客デジタルエクスペリエンス 用語集 オムニチャネルコマース・D2Cブランドの成長のために

 

GraphQL と REST API: 究極の比較

マイクロサービス、モノリス、さらにはミニサービスまで、サービスはどこにでもあります。

データを抽出、変換し、あるデータから別のデータに移動する必要があります。これを行うには、これらのさまざまな種類のサービスが相互に通信する必要があります。

WebSocket、gRPC、AMQP、Kafka、Nats など、多くの通信技術があります。

この解説コラムでは、同期通信パターンの一種である REST API と GraphQL という 2 つの人気のあるテクノロジーを詳しく見ていきます。

リクエストとレスポンスのパターン

Rest API と GraphQL とは何か、そしてそれらの違いについて詳しく説明する前に、まずリクエスト/レスポンス パターンとは何なのかを説明したいと思います。

REST API を考えると、GraphQL はリクエストとレスポンスのパターンの実装です。

要求/応答パターンでは、1 つのサービス (クライアントとして機能) が要求を送信し、1 つ以上の他のマイクロサービスまたはシステムからの応答を待ちます。クライアント アプリケーションのビジネス ロジックは応答を受信するまでブロックされ、クライアント アプリケーションが応答を受信するまで通信チャネルは開いたままにしておく必要があります。

要求/応答パターンのほとんどの実装では、HTTP などのプロトコルを活用しながら、サービス間でデータを転送するためのさまざまなデータ表現と交換技術を使用します。

REST APIとは何ですか

REST APIとは何かを紹介する前に、REST、API、RESTfulとは何かについて説明しましょう。

• REST は実際には、REST の作成者である Roy Fielding が、ソフトウェア アーキテクトやプログラマーが堅牢で信頼性が高く、スケーラブルなアプリケーションと API を構築できるように文書化したスタイル、または物事のやり方です。
• API は、アプリケーションを世界に公開する方法を表す簡単な用語です。
• REST の原則に従って設計された API はRESTfulと呼ばれます。

これらの定義に基づいて、 REST API はREST の原理で設計された API として考えることができます。

REST の重要な概念はリソースです。リソースは通常、顧客や製品などの単一のビジネス オブジェクト、またはビジネス オブジェクトのコレクションを表します。 REST は、URL を使用して参照されるリソースを操作するために HTTP 動詞を使用します。たとえば、GET リクエストはリソースの表現を返します。これは多くの場合 JSON オブジェクトの形式ですが、バイナリなどの他の形式も使用できます。 POST リクエストは新しいリソースを作成し、PUT リクエストはリソースを更新します。

HTTP 操作の形式で送信されたすべてのリクエストはそのエンティティに対して実行されます。 HTTP POST メッセージを使用して、指定された URL にある注文リソースに注文作成リクエストを送信できます。同様に、HTTP GET、PUT、DELETE リクエストをそれぞれ送信することで、注文リソースを取得、更新、削除できます。

• API を REST として設計する場合、ビジネス オブジェクトに対して実行したい操作を HTTP 動詞にマッピングする方法が非常に難しい場合があります。たとえば、PUT は更新操作に使用されます。注文をキャンセルしたい場合、注文を修正したい場合など、PUT を使用してこの動作を表現するのは困難です。また、更新は冪等でない場合があります。これは、PUT を使用するための要件です。この課題のため、以前は POST /orders/{orderId}/cancel、POST /orders/{orderId}/revise などのサブリソースを含む RESTful エンドポイントが見られました。
• 1 つのリクエストで複数の関連オブジェクトを取得する場合はどうでしょうか。ああ、これも難しいですね。たとえば、クライアントは注文と注文の消費者を取得したいとします。純粋な REST API では、クライアントは少なくとも 2 つのリクエスト (1 つはオーダー用、もう 1 つはコンシューマ用) を行う必要があります。これにより、後ほど説明する GraphQL などの代替 API テクノロジの人気が高まりました。

こうした課題にもかかわらず、REST は API の事実上の標準となっているようです。ビジネス ユース ケースがリソース指向モデルに適合する場合 (HTTP リソースや操作などのビジネス エンティティと機能を表すことができます)。

REST APIのメリット

• シンプルでわかりやすいアーキテクチャ。Web アプリケーションでの実装と使用は簡単です。
• 柔軟性があり、さまざまなプログラミング言語やフレームワークで使用できます。
• ステートレスとは、サーバーがクライアントの状態を追跡する必要がないことを意味し、障害に対する回復力が高まり、拡張が容易になります。
• 異なるクライアントのセット (Web クライアント、モバイル クライアント) と相互運用します。
• クライアントのリクエストに基づいて、さまざまなコンテンツ タイプ (JSON、CSV、XML) をサポートします。人間が読めるテキストベースのメッセージ形式を提供します。
• キャッシュをサポートします。これにより、サーバーへのリクエストの数が減り、Web アプリケーションのパフォーマンスが向上します。

REST APIのデメリット

• リクエスト/レスポンス形式の通信のみをサポートします。したがって、可用性が低下します。通信するには、サービスとクライアントが稼働している必要があります。
• クライアントはサービス インスタンスの場所 (URL) を知っている必要があります。マイクロサービス時代では、多くの種類のサービスがあるため、クライアントはサービス インスタンスを見つけるためにサービス検出メカニズムを使用する必要があります。
• 1 回のリクエストで複数のリソースを取得するのは困難です。
• 複数の更新操作を HTTP 動詞にマッピングするのが難しい場合があります。
• 固有のセキュリティ メカニズムが提供されていないため、認証や認可などのセキュリティ対策を実装するのは開発者次第ですが、これは困難な場合があります。
• HTTP および XML/JSON の使用に依存しているため、他の通信プロトコル (バイナリなど) よりも効率が劣る可能性があり、その結果、大量のデータが転送される可能性があります。
• REST 上に構築された Web アプリケーションが進化するにつれて、既存のクライアントとの下位互換性を維持しながら、API への変更や更新を管理することが困難になる場合があります。

全体として、REST API は広く使用されている強力なアーキテクチャですが、課題や制限がないわけではありません。

GraphQLとは何ですか

GraphQL は、API 用のオープンソースのデータ クエリおよび操作言語であり、サーバーによって定義された型システムを使用してそれらのクエリを実行するためのランタイムでもあります。 2012 年に Facebook によって開発され、2015 年にオープンソース プロジェクトとしてリリースされました。

RESTful サービスとは異なり、GraphQL はクエリをリクエストとしてマイクロサービスに送信するという概念に基づいています。クエリはクライアントが関心のあるデータを表し、サービスのロジックは既存のデータとビジネス ロジックを使用してこれらのクエリを実行します[2] 。

GraphQL を使用すると、クライアントはどのデータが必要か、どのように、どのような形式で必要かを決定できます。これは、クライアントが受信する応答データを制御できない RESTful サービスとは異なります。 GraphQL は、消費者およびサービスとの主な対話スタイルとして主にクエリ、ミューテーション、およびサブスクリプションを使用します[3] 。

クライアントは製品データの一部のみを必要としています。この意図を GraphQL クエリとして示します。私たちのサービスは GraphQL を実装しているため、この意図を理解し、クライアントが関心のあるデータのみを実行して返します。クライアントが複数のエンティティを取得したい場合、GraphQL クエリは 1 つだけ作成されるため、複数のクエリを作成する必要はありません。

REST と比較して、GraphQL は、オーバーフェッチ (コンシューマーにとって必要のない冗長データを取得する) やアンダーフェッチ (必要なデータの一部のみを取得するため、残りのデータをフェッチする後続のリクエストが発生する) を発生させずにデータを取得する効率的な方法を提供します。 ）。 GraphQL を使用すると、コンシューマーは 1 回のリクエストで必要な正確なデータをフェッチできます。 GraphQL には、検証と型チェック、詳細なエラー処理、下位互換性のあるバージョン管理など、他の利点もあります。

GraphQLの利点

• クライアントは必要なデータのみをリクエストし、不必要なデータのフェッチを避けることができるため、より高速で効率的なデータ転送が可能になります。
• クライアントはこれを使用して、複数のソースや API からデータをクエリしたり、受信したデータの形状や構造を簡単に変更したりできます。したがって、GraphQL は、サービスからビジネス データを取得するために必要なサービス呼び出しの数を減らします。
• これにより、サブスクリプション (内部で WebSocket を使用) を通じてリアルタイム更新が可能になり、リアルタイム データを必要とするアプリケーションで役立ちます。
• これには、より優れたツールとドキュメントを可能にする強力なシステムがあり、開発者が API を理解し、使用することが容易になります。

GraphQLの欠点

• データの取得と操作が簡素化されますが、アプリケーションのアーキテクチャが複雑になることもあります。
• GraphQL サーバーの実装は、特に GraphQL を初めて使用するチームにとっては、REST API の実装よりも複雑になる可能性があります。
• 効率を向上させることができますが、特に大規模なデータセットの場合、誤用するとパフォーマンスの問題が発生することもあります。
• GraphQL の構文と概念を学習して習得するには時間がかかる場合があり、これが一部のチームにとって導入の障壁となる可能性があります。

GraphQL は最新の API やアプリケーションを構築するための強力なツールですが、特定のプロジェクトに使用することを決定する前に、その利点と欠点を慎重に比較検討することが重要です。

結論: GraphQL と REST API

REST API と GraphQL の主な違いは次のとおりです。

データの取得: REST API では、クライアントはサーバーに対して複数のリクエストを作成して、さまざまなデータを取得する必要があります。これにより、オーバーフェッチ (必要以上のデータを取得する) またはアンダーフェッチ (十分なデータを取得しない) が発生する可能性があります。 GraphQL では、クライアントは必要なデータを正確に指定し、サーバーはそのデータのみを返します。これにより、サーバーへのリクエストが減り、データの取得がより効率的に行われるようになります。

1. URL 構造:
   REST API では、各エンドポイントは URL で表され、クライアントはデータにアクセスするために各エンドポイントの URL を知っている必要があります。 GraphQL にはエンドポイントが 1 つだけあり、クライアントは必要なデータを指定する GraphQL クエリを送信します。
2. データ モデリング:
   REST API では、サーバーはデータ モデルとそのデータを表すエンドポイントを定義します。 GraphQL では、クライアントがデータ モデルを定義し、サーバーがクライアントのクエリに基づいてデータを提供します。
3. キャッシュ:
   REST API では、クライアントはサーバーに対して複数のリクエストを行うことを避けるために、特定のエンドポイントの応答をキャッシュできます。 GraphQL では、クライアントは特定のクエリに対する応答をキャッシュできます。これには、複数のエンドポイントからのデータが含まれる場合があります。
4. スキーマ検証:
   GraphQL では、サーバーはデータ モデルとそのデータに対して実行できる操作を記述するスキーマを提供します。これは、エラーを防止し、API に関するより適切なドキュメントを提供するのに役立ちます。 REST API には、スキーマ検証の標準はありません。

REST API と GraphQL はインターネット経由でデータを取得する方法ですが、データの取得、URL 構造、データ モデリング、キャッシュ、スキーマ検証に対するアプローチ方法が異なります。

REST API は多くのアプリケーションでうまく機能する確立されたアプローチですが、GraphQL はデータ取得の柔軟性と効率性を高める新しいテクノロジーです。

REST API と GraphQL のどちらを選択するかは、アプリケーションの特定のニーズ、データ モデルの複雑さ、アプリケーションのパフォーマンス要件によって異なります。

---

顧客デジタルエクスペリエンス ソリューション [オムニチャネル発送代行]

オムニチャネルコマースビジネスに適した顧客の購入（購買）体験ニーズ に添ったオペレーションを設計・構築するツールを選定したら、 富士ロジテックホールディングスの EC物流サービス ・物流・発送代行 ・返品・交換 サービスをその施策の一部として活用することを検討してください。

富士ロジテックホールディングスがDNVBとその一カテゴリーDTC/D2C 3.0 コマースビジネスに提供するものには

• 全国のフルフィルメント センターからの D2C（DTC） および B2B注文の EC:eコマース フルフィルメント
  (ビジネスに最適なフルフィルメント センターを選択使用可能)
• 標準および 配達予定日 指定のeコマース配送サービス
• eコマースの商品の 配送情報 の提供と、 注文/追跡情報 と返品対応
• 思い出に残る 開梱体験：Unboxing を提供するキッティングおよびカスタマイズ サービス
• データ分析により、顧客のe コマースの配送方法、顧客の支出金額、配送方法ごとの平均コスト、配送方法ごとの注文の配達にかかる時間、返品理由などについての顧客のインサイト：洞察の提供
• 越境ECに伴う、国際 eコマース配送 (米国、カナダ、英国、欧州連合、オーストラリ、アジアなど、その他の国へ)

富士ロジテックホールディングスが連携、推奨するコマースソフトウェアは、 プラットフォームシステム、 マーケットプレイス、EDI ソリューション (小売業者の Webサイトや店舗での注文を処理するため)、およびその他の販売チャネルと統合して、e コマース、 オムニチャネルの フルフィルメントを自動化します。

富士ロジテックホールディングスを利用・活用すると、日本中に フルフィルメント センター のネットワークを通じて、 小売・製造事業者 は、商品在庫を 分散保管・分散出荷 サービスを活用して、e コマースの配送コストと配達時間を削減することができます。

D2Cビジネスサポート：相談・問い合わせ

 

オムニチャネルコマースシステム＆フルフィルメント戦略:

オムニチャネルコマースシステム＆フルフィルメント は、購入・販売チャネルとフルフィルメントセンターを統合して、顧客にまとまりのある ショッピングエクスペリエンス を提供します。

次世代オムニチャネルサービスを通じて、 成功する D2C チャレンジャー ブランド をはじめとして、 購入後の体験（Post-Purchase ポストパーチェス） の向上に注力すると、エンゲージメントと 顧客ロイヤルティ が向上し、リピート購入と顧客維持の可能性が高まります。

 

AOV・CLVを向上させる多彩なサービスを提供します。

• Lexica オムニチャネルコマースから、再販・リコマースまで対応するMACH・コンポーザブルコマースシステム
• E-Aspro 通販からEコマース向け ERP: 定義、機能、メリット（通販基幹システム）　
• エスキュービズム「EC-ORANGE」
• 店舗販促・EC販促専用のCRM・MAツール「EC Intelligence」

お気軽にご相談ください。Shopifyなどのフィット＆ギャップ　アドバイスをします。

商品追跡情報・配送予定日設定・返品・交換・修理、特別問い合わせ/ご相談

 

通販・ D2C・ Eコマース 事業者の EC物流代行・発送代行 ・オムニチャネル コマースでの流通加工から店舗物流までを、
一般社団法人 通販エキスパート協会 ：「通販CXマネジメント」・「フルフィルメントCX」認定スペシャリスト メンバーとスタッフがサポート致します。

全国11拠点のDC/FCから、先進 RaaSマテハンロボット ・RFID などと、注文管理システム（OMS）・倉庫管理システム（WMS）とコマースシステム をAPIで連携して、 物流・発送代行サービス を「スタートアップ特別限定プラン から、100億円を超える事業者に最適な 分散保管・分散出荷、 返品・交換 サービスまでを一貫でデザインする「 顧客購買後体験 」によって、LTVの向上が実現できる「 感動物流サービス 」を提供中です。物流業界の最新トレンドを盛り込んだ お役立ち資料 も無料でご提供しています。

購入後体験（ポストパーチェス）　顧客中心のエクスペリエンスのために