REST（Representational State Transfer）とは、ウェブサービスを構築するためのアーキテクチャスタイルであり、プロトコルである。スケーラビリティ、シンプルさ、変更可能性を重視するため、ウェブ・アプリケーション・プログラミング・インターフェイス（API）を設計するための一般的なアプローチである。

のようなAPIプロトコルを管理する厳格なフレームワークとは異なります。単純オブジェクトアクセスプロトコル (SOAP)やExtensible Markup Language remote procedure call (XML-RPC)のようなAPIプロトコルを管理する厳密なフレームワークとは異なり、RESTプロトコルは事実上どのようなプログラミング言語でも構築でき、様々なデータフォーマットをサポートするため、API開発のプロセスを簡素化するために歴史的に採用されてきた。

しかし、いくつかのREST代替の出現が、今後10年間のAPI開発の新たな火種を形成しつつある。このトレンドには、イベント駆動 API、GraphQL、gRPCのような他のプロトコル、パターン、技術が含まれる。これらのプロトコルが成熟し、より広く受け入れられるようになるにつれ、API開発者は様々なプラットフォームでREST代替を展開する最善の方法を理解することが不可欠になるだろう。

これらの REST 代替プロトコルの人気の理由と、現場での利用をサポートする最も一般的なユースケースを探ってみよう。

なぜREST代替が勢いを増しているのか？

RESTful APIが人気なのは、柔軟で理解しやすく、ハイパーテキスト転送プロトコル（HTTP）をサポートするあらゆるプログラミング言語やプラットフォームと互換性があるからです。また、HTTPのキャッシュや負荷分散機能を活用できるため、スケーラブルな分散システムの構築にも適している。

RESTは、データを表すリソースとURI（Uniform Resource Identifier）を使って簡単に変更できることを優先している。これは、開発者が既存のクライアント・アプリケーションを壊すことなくAPI構造を変更できることを意味する。

では、なぜ開発者は他のものを使うのだろうか？説得力のある理由がいくつかある：

複雑性の進化。REST APIは、SOAPのような以前のAPIプロトコルの複雑さを克服するために設計されているが、エンドポイントやリソースの数が増えるにつれて保守が困難になる可能性がある。これは開発者がAPIを理解し修正することを困難にする。
パフォーマンス。いくつかのユースケースでは、REST APIはスケーラブルで多くのリクエストを処理できる。しかし、データを取得するために複数のラウンドトリップリクエストに依存するため、リアルタイムまたは低遅延のアプリケーションにはより良い選択肢があるかもしれない。
進化するデータ要件。REST APIは、新しいユースケースやデータ構造をサポートするために大幅な変更が必要になる場合があり、バージョン管理や互換性の問題が発生し、複雑さと開発時間が増大する。
特定のユースケースの要件。リアルタイムのデータストリーミングや低消費電力のモノのインターネット（IoT）デバイス（前述のとおり）など、RESTよりも他のプロトコルの方が適しているような特定のユースケースがあります。
開発者の好み。開発者は、代替プロトコルの方が使い慣れたり、RESTにはない特定の機能や利点があるため、代替プロトコルの使用を好むかもしれません。

REST APIの代替

ここでは、RESTに代わる7つのAPIを紹介する：

GraphQL

GraphQLはAPI用のランタイムおよびクエリ言語で、クライアントが必要なデータのみをリクエストおよび受信できるため、RESTよりも効率的です。GraphQLを使用すると、クライアントは必要なデータを正確に指定し、RESTのように異なるエンドポイントに複数のリクエストを行う代わりに、1回のリクエストでそれを取得することができます。複雑で進化するデータ要件を持つデータ駆動型アプリケーションには最適な選択だ。

厳密なデータ検証を必要とするアプリケーションや、多種多様なクライアントをサポートする必要があるアプリケーション、あるいはソーシャルメディアのようなユーザー向けのアプリケーションには最適な選択ではないかもしれない。それでも、柔軟で効率的なデータ検索と操作を必要とする状況では、RESTに代わる優れた選択肢となる。これは特に、複雑なデータモデルを持つアプリケーションや、接続性が制限されたモバイルアプリケーションに当てはまります。

gRPC

gRPCはRPC APIを構築するためにGoogleが開発したオープンソースのフレームワークである。gRPCはプロトコル・バッファと言語にとらわれないデータ・シリアライズ・フォーマットを使用して効率的なデータ転送を行うため、高性能なアプリケーションに最適です。

gRPCは、大量のデータ操作や、多種多様なクライアントをサポートする必要があるアプリケーションには最適ではないかもしれません。しかし、gRPCは高いパフォーマンスと低いオーバーヘッドで知られており、サービス間の高速で効率的な通信を必要とするアプリケーションに適しています。

ウェブソケット

WebSocketはウェブソケット・プロトコルは、クライアントとサーバー間の双方向リアルタイム通信を可能にする。リクエスト/レスポンスベースのRESTとは異なり、WebSocketはデータが利用可能になるとすぐにサーバーからクライアントにプッシュできるため、チャットアプリケーションやオンラインゲームなど、リアルタイムの更新が必要なアプリケーションに最適です。

WebSocketは、複雑なデータ操作を必要とするアプリケーションや、スケーラビリティが懸念されるアプリケーションには最適な選択ではないかもしれない。しかし、クライアントとサーバー間の全二重の持続的な接続のおかげで、リアルタイムの通信と低レイテンシーが要求される場合には輝きを放ちます。RESTは、あまり効率的でないリクエスト／レスポンス・モデルを使用している。

MQTT

MQTTは、IoTデバイス用に設計された軽量でオープンソースのメッセージング・プロトコルです。これはパブ/サブプロトコルで、パケットサイズが小さく、帯域幅が低いため、制約のあるネットワークや処理能力に制限のあるデバイスに最適です。MQTTは断続的なネットワーク接続にも対応し、信頼性の高いメッセージ配信を保証するためにQoS（Quality of Service）レベルをサポートしている。

MQTTは、複雑なインタラクションやデータ操作アプリケーションには最適ではない。しかし、帯域幅が狭く、バッテリー寿命が短いユースケース（MQTTは、デバイスがメッセージ間で「スリープ」することを可能にし、IoTデバイスのバッテリー寿命を延ばす）には、優れた機能を提供します。

イベント駆動型アーキテクチャ（EDA）

EDAでは、イベントがトリガーとなり、システム内の異なるコンポーネントやサービス間で変更が伝達されます。これにより、リアルタイムかつリアクティブなデータ処理が可能になり、RESTベースのシステムではリソース集約的で時間のかかる、リソースの繰り返しポーリングの必要性を減らすことができます。

EDAは、リアルタイムのデータ処理、スケーラビリティ、システム内の異なるコンポーネントやサービス間の緩やかな結合を必要とするアプリケーションに適したRESTの代替です。また、マイクロサービス・アーキテクチャにも適しており、各マイクロサービスが独立して動作し、イベントを通じて他のサービスと通信することができる。これにより、システム全体のスケーラビリティ、柔軟性、耐障害性が向上する。

ファルコール

企業は開発においてもイノベーションを推進することができる。FALCORは、効率的で柔軟なAPIを構築するためにNetflixが開発したJavaScriptライブラリだ。HTTPリクエストでアクセスされる個々のリソースではなく、相互に接続されたパスのグラフとしてデータを表現する。以下のような利点がある：

WebSocketのサポートにより、ポーリングを繰り返すことなく、リアルタイムのデータ更新をクライアントにプッシュできる。
クライアントが必要なデータを指定し、APIが要求されたデータで応答する、宣言的データ・フェッチ。これにより、クライアント側のコードが簡素化され、ネットワーク経由で送信されるデータ量が削減される。

FALCOR」という名前は何の略でもない。Netflixの開発者が、データ検索に対するライブラリのアプローチを表すために選んだものだ。1980年代の映画『ネバーエンディング・ストーリー』に登場する同名のキャラクター、ドラゴンのような生き物は、異なる次元や世界を旅することができ、FALCORの複雑なデータグラフをナビゲートする能力とよく似ている。

機能

PubNubの関数はJavaScriptのイベントハンドラで、PubNubのメッセージやHTTPS経由のRESTful APIのリクエスト/レスポンス形式で実行できます。Node.jsやExpressに慣れている人にとって、On Requestイベントハンドラの開発は非常によく似ている。機能は、チャットモデレーションや言語翻訳のような新しいまたは追加のリアルタイム機能を展開することができます。

当社のネットワーク内でコードを実行するか、当社の既存の統合機能を活用して、メッセージを変換、再ルーティング、増強、フィルタリング、集約し、スパマーの検出とブロック、平均値の測定などを行います。すべてのコードは低レイテンシーのためにエッジで実行され、独自のインフラを構築する必要がないほど堅牢です。

一度に1つのREST代替技術でイノベーションを促進

RESTの代替機能は、REST APIが直面する課題を解決する能力によって人気を集めています。それぞれの代替手段は、独自の強みと使用事例を持っています。REST の代替手段を選択する際には、アプリケーションの具体的なニーズや要件（ライブイベントの規模や、Web3のリアルタイム機能など）を考慮するとともに、各 REST 代替手段の長所と限界を考慮することが不可欠です。

最終的には、これらの選択肢を検討することで、開発者は最新のアプリケーションのニーズを満たす、より効率的で効果的なAPIを構築することができます。

あなたのアプリケーションに命を吹き込みましょう。お問い合わせリアルタイムプロジェクトについてご相談ください、実際に動作しているものをご覧ください.

PubNubはどのようにあなたを助けることができますか？

この記事はPubNub.comに掲載されたものです。

PubNubのプラットフォームは、開発者がWebアプリ、モバイルアプリ、IoTデバイス向けにリアルタイムのインタラクティブ機能を構築、提供、管理できるよう支援します。

私たちのプラットフォームの基盤は、業界最大かつ最もスケーラブルなリアルタイムエッジメッセージングネットワークです。世界15か所以上で8億人の月間アクティブユーザーをサポートし、99.999%の信頼性を誇るため、停電や同時実行数の制限、トラフィックの急増による遅延の問題を心配する必要はありません。

PubNubを体験

ライブツアーをチェックして、5分以内にすべてのPubNub搭載アプリの背後にある本質的な概念を理解する

セットアップ

PubNubアカウントにサインアップすると、PubNubキーに無料ですぐにアクセスできます。

始める

PubNubのドキュメントは、ユースケースやSDKに関係なく、あなたを立ち上げ、実行することができます。

REST APIに代わる7つの選択肢