RESTlessnessに打ち勝つ

原文(投稿日：2019/02/01)へのリンク

GraphQLやgRPC，Apache Kafkaといった新しいAPIプロトコルが，RESTに基づいたHTTP APIに代わるものとして人気を集めています。この記事では，RESTパラダイムの長所は1対1のプロトコル比較では表現できない，という主張を展開します。RESTの代わりを探すのではなく，ソフトウェアエンジニア産業は，成熟したRESTエコシステムを基盤として，新たなプロトコルの技術的長所を探求する手段を模索するべきです。

"RESTlessness"を克服する

GraphQLやgRPC，Apache Kafkaといった新しいAPIプロトコルが，RESTに基づいたHTTP APIに代わるものとして人気を集めています。この記事では，RESTパラダイムの長所は1対1のプロトコル比較では表現できない，という主張を展開します。RESTの代わりを探すのではなく，ソフトウェアエンジニア産業は，成熟したRESTエコシステムを基盤として，新たなプロトコルの技術的長所を探求する手段を模索するべきです。

プロトコル，パラダイム，偽りの2分法 ...

バンクーバ在住のTim Bray氏による先日のブログ記事"Post-REST"は，多くの意味でソフトウェア産業の注目を集めました。APIの利用が増えるにつれて，果たしてREST¹はWeb APIとして理想的な通信規約なのだろうか，という懐疑的な意見が現れています。オープンなWeb通信という当初の目的に加えて，現在のRESTは，Webアプリケーションデータの提供やマイクロサービス間通信，インフラストラクチャの管理と自動化の促進，さらにはメッセージングやイベント分散，ストリーミングといった非同期パターンにまで使用されています。

Timの記事はRESTの使用法，認識されている制限，代替としての新たなプロトコル(GraphQLやgRPC)の興隆，Web API通信の将来に対する考察などをうまくまとめています。記事の主張には概ね賛成できますが，この話題についてはもっと語るべきことがあると思います。つまり，単にRESTの代替を探すのではなく，RESTの持つ長所をこれら新しいプロコトルのイノベーションと融合させて，分散ソフトウェアエコシステムにおける革新的な通信手段を見い出すべきではないか，と思うのです。

新しいプロトコル，古い戦線，偽りの2分法

ここ数年，ソフトウェア開発コミュニティでは，RESTに対する反感が高まっています。RESTの制約に対する不満を挙げて，代わりとなるプロトコルや通信アプローチを紹介する記事が数多く発表されています。

"RESTはxだからyを使おう"といった論調で，GraphQLやgRPC，非同期通信，あるいはそれらほど有名ではない選択肢を推奨する記事もあります。その主張は次のようなものです。

• GraphQLはRESTより優れている。コンシューマが受信するデータをコントロール可能であり，APIプロバイダがリソースをサーバ側に集約できるからだ。
• gRPC(とプロトコルバッファ)はRESTより優れている。タイプセーフで、バイナリシリアライゼーシfielding/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures"で定義されました。この論文の本当の目的は、"ソフトウェアアーキテクチャを理解するためのフレームワークの定義して ... ネットワークベースのアプリケーションソフトウェアのアーキテクチャ的設計をガイドする"ことにありました。その中でRESTは、World Wide Webの設計思想を体系化したアーキテクチャスタイルの一例として、インターフェースの発展性、拡張性、汎用性が強調されています。上述した新しいアプローチのコンテキストと比べると、初期のRESTの問題空間は広いものでした。

   

  広く知られているような、ネットワークベースのデータ共有やブラウザを越えたサービスにWebを使うというアイデアは、ごく一般的なものです。Fielding氏の著作は瞬く間にソフトウェア開発者の間に広まり、実践されました³。このRESTの登場そのものが偽りの2分法の結果であり、そこではSOAPが悪役だったのです。SOAPがWebのプロトコルをすり抜ける方法を提供しようとしていたのに対して、RESTのアプローチはそれを受け入れました。"Web上にあるだけでなく、Webそのもの"であるというRESTの発想は、Webベースのソリューションをすでに構築していたソフトウェアエンジニアにとって、より直感的な選択肢だったのです。

  SOAPとWS-*エコシステムの複雑さが増すにつれて，RESTの相対的なシンプルさとユーザビリティが勝利を収めました。その後，同じような理由から，Web APIのデファクトデータフォーマットとしてのJSONが，それまでのXMLを駆逐しました。Webコンピューティングパラダイムの利用が新たなシナリオ -- 企業アプリケーションの統合，クラウドプロビジョニング，データウェアハウスクエリ，IoT -- へと広がるにつれて，REST APIの採用も増えていったのです。

  ところで，もしも特定の使用シナリオを個別に検討するのであれば，RESTの適用性にはいくつかの弱点があるかも知れませんし，より理想的な他の通信アプローチが存在する可能性もあります。しかし，そのような検討は，RESTの汎用性の持つ力を無視したものです。RESTの持つ普遍性により，AJAXの呼び出しに習熟した開発者であれば，クラウドインフラストラクチャのプロビジョニングのためにAWSのAPIを呼び出す方法を直感的に把握できます。Webベースのソーシャルネットの開発者ならば，モバイルアプリケーションを短期間に構築することができます。さらに，エンタープライズ開発者には，自身の熟知した方法で，分割されて相互通信するマイクロサービスを新たに構築することが可能になるのです。ソフトウェアエンジニアリングでは，デリバリに対する障壁が，マシンよりも人間側にあることが少なくありません。十分に理解されているアプローチには価値があります。技術的には最適だがニッチなソリューションよりも，納期に大きく影響することが多いのです。

  このような普遍性は，RESTエコシステムに堅牢性ももたらします。Swagger -- 現在はOpenAPI -- は，開発者がAPIを記述し，設計し，使用するためのメタデータ仕様として組織に登場しました。拡張性と転送可能性を備えた，認証と承認のためのフレームワークを提供します⁴。"API Management"は，レート制限，動的ルーティング，キャッシングといった機能セットとして登場し，一般的にREST API提供に有用であることが証明されています。RESTパラダイムの持つ包括性とエコシステムの完成度は，ソフトウェアシステムにおけるネットワークベースの通信アプローチとして，RESTが大きな価値を持っていることを表すものなのです。この偏在性が技術的な詳細よりも，"Webが動作する仕組み"としてのRESTに由来するものであることは，ほぼ間違いありません。

  ポストWebパラダイムにおける通信

  ソフトウェアエンジニアリングにおけるWebの影響は計り知れません。RESTの出現と前後して，ソフトウェアエンジニアリングの世界にもまた，オープンソースやアジャイル，DevOps，ドメイン駆動設計，マイクロサービスアーキテクチャなどが現れています。これらのムーブメントはいずれもWebが可能にしたもので，すべてが一括して，ソフトウェアデリバリにおける要素としての人間の重要性を高めています。クラウドコンピューティングが可能にした柔軟性と利便性に加えて，継続的に稼働し継続的に進化する疎結合なアプリケーションとサービスを特徴として持つ，新たなソフトウェアエンジニアリングのパラダイムが登場しました。Tim Bray氏は自身の記事を"ポストREST"と呼びましたが，おそらくこの新しいパラダイムは"ポストWeb"と呼べるでしょう。このパラダイムの特徴はFieldings氏のRESTの持つ元々の原則と一致しているので，RESTを捨てて最初からやり直すのは理に叶いません。一方で，20年間の技術革新をまったく無視するというのも同じような愚策です。

  では，この新たなパラダイムは，RESTの価値をどのように進化させるのでしょうか？ソフトウェア開発に"APIファースト"を適用する，すなわち，アプリケーションやサービスのマシンインターフェースを設計をUIと同じように重視し，それぞれのドメインに責務を持つチームの開発作業を分離する手段として，それらのAPIを使用する組織の数が増えています。OpenAPIは，実装に左右されないインターフェース仕様として，この方法論でしばしば重要な役割を果たしています。ポスドWebパラダイムに従って，これはソフトウェアシステムの開発や修正に関与するさまざまな人たちに利益をもたらします。これと同じ価値をイベントベースの通信に提供することを目標とするプロジェクト -- Fran Mendez氏のAsyncAPI -- がすでに実施されています。同じように，Mike Amundsen氏とLeonard Richardson氏は，ネットワークベースのアプリケーション間通信のセマンティクスを記述するためのALPS仕様を開発しています。このような取り組みは，分散システム構築における設計時の課題に対処しようとするものです。

  RESTの価値をクラウドネイティブなランタイムに拡張する方法もあります。マイクロサービスへの移行により、これまではプロセス間通信(IPC)が使用されていた場所に、ネットワークバウンダリが導入されました。これらの物理的な境界は、これまで述べたような人々の利益を達成するために、ビジネスドメインの境界を反映している場合があります。ただし、ネットワーク遅延の存在やサービス呼び出しチェーンが潜在的に抱える，暗黙的な実行時トレードオフが存在します。

  サービスメッシュパターンはコンテナベースのシステムの持つこれらの問題に対処するもので、アプリケーションコンポーネント間のすべてのネットワーク通信を処理する"サイドカー"サービスプロキシを備えています。サービスメッシュのトポロジは、アプリケーションコンテナと関連するサイドカーとの間にIPCが改めて導入された，という意味に他なりません。そうではあっても、サービスプロキシは一般的にプロキシされたメッセージのトランスポートプロトコルを変更しないので、アプリケーションコンテナの開発者は依然として、コード内でネットワークプロトコルを指定する必要があります。

  これらアプリケーション開発者は、そもそもプロトコル処理を扱うべきなのでしょうか？そうではなく、もっと抽象的な要求を処理するようにして、サービスプロキシがプロトコルマッピングやコード変換、送信を処理するべきではないでしょうか？この疑問は検討の余地があります。そして、RESTの持つ普遍的な設計時の理解は、抽象化の出発点となる可能性を持っています。これらはいずれも、RESTの偏在性を活用してポストWebパラダイムを強固なものにすることの可能な分野の一部に過ぎないのです。

  RESTlessの少ない未来へ

  喧伝されるテクノロジトレンドは多くの場合、古いアプローチを新たなアプローチで置き換えることを謳います。しかし現実には、ソフトウェアエンジニアリングの進化は通常、層を成して起こるものです。新たな技術革新が、それに続く新たなイノベーションの基礎を築くのです。GraphQLやgRPCやKafkaのような新しいAPIプロトコルは、一部の分散処理のシナリオにおいては、リソースを基盤として、JSONでエンコードされ、HTTPで転送されるメッセージを置き換えるでしょう。しかしながら、分散システムの進化におけるRESTの遺産は、その実装の詳細よりも、その偏在性へとつながった特質である、普遍的な接続性のためのフレームワークの提供、サービスコンシューマのプロバイダからの分離、利便性とアクセス可能性の重視などにこそ見出されるべきです。これらの特性が、元来はWebのアーキテクチャスタイルの定義であったRESTを、ソフトウェアエンジニアリングのポストWebパラダイムにおける基礎に成し得たものなのです。

  脚注

  1. この記事はRESTの定義を論じることを目的としたものではありません。"REST"ということばは、Fielding氏の元々の意味に加えて、HTTP上で展開されるCRUD形式のAPIという意味でも使用しています。
  2. REST/gRPC/GraphQLの決定コンテキストに関する実践的分析は、Phil Sturgeon氏のこちらのブログ記事を参照してください。
  3. ... HTTP経由でRESTからHTTP上のCRUDを抽出したいという願望は、非常に早い段階から進められていました。こちらを参照。
  4. SOAPとの2分法に戻ると，この組織的な標準開発は，2000年始めのWebサービスブームの真っ只中に登場した，W3CやOASISといった標準の急増とは対照的です。

  この記事に記載した"RESTの歴史"のリソースを見つけてくれた，Mike Amundsen，Erik Wilde，Irakli Nadareishvili，Ronnie Mitraに感謝します。

  著者について

  Matt McLartyは経験豊富なソフトウェアアーキテクトです。Broadcom企業であるCA TechnologiesではAPI Academyチームのリーダを務めていて，革新的なエンタープライズレベルのAPIやマイクロサービスソリューションを設計する企業との密接な関係の下で活動しています。氏はこれまで，ソフトウェアベンダとクライアントとを問わず，統合やリアルタイムトランザクション処理の分野で，幅広く活動してきました。最近では，"Microservice Architecture"と"Securing Microservice APIs"という書籍を，O'Reillyから共著で発行しています。