私たちは過去数年間にわたって，従来のデータベース技術の代替となる，いわゆる NoSQL をめぐる議論が日増しに高まっていくのを目の当たりにしてきた。高性能トランザクションに関するワークショップでも，あるいはこの InfoSQL でも，NoSQL は今や REST や SOA などと同じように無視しがたい存在となっている。2009年の議論や，さらに以前の 2007 年に Postgres と Ingres のオリジナル開発者のひとりである Mike Stonebraker 氏による RDBMS 終焉の予想に見られるように，初期の議論は従来の RDBMS を NoSQL 実装で置き換えることを目指していた。しかし Twitter や Amazon といった REST ベース の企業が NoSQL の強力な擁護者となるにつれ，REST と NoSQL という２つの技術の併用が必然的な流れとなったのだ。
その一方で Ganesh Prasad 氏は 先日のポスト において，NoSQL の出現は私たちに REST の中心的な特徴のひとつを再評価するように求めているのではないか，と問いかけている。氏の考えによると REST のアプローチには，実施する上で重大な障害となる２つの側面がある。
ひとつは，汎用的かつ実用的なモデルと思われるピアツーピアではなく，クライアント／サーバをモデルに用いていることです。ふたつめは[...]，ステートレス (あるいはステートフルなものをクライアントで管理するか，あるいはリソースとしてモデル化する) であることが強制されている点です。
氏がポストで取り上げているのは，ステートレスな側面の方だ。ステートと REST については実際に他のソースからも，何年間にもわたって数多くの情報が寄せられている。例えば Bill Burke 氏は，数年前からこの面に関する議論を続けている。
REST でのステートレスとは，クライアントのセッションデータがサーバ上に存在しないことを意味しています。サーバは，自身が公開するリソースのステート(状態)を記録し，管理するだけです。セッション固有のデータが必要な場合は，クライアントがそれを保持して，各要求時に必要に応じてサーバに送信しなければなりません。サービス層はクライアントセッションを維持管理する必要がないため，スケールが非常に容易になると同時に，クラスタ環境におけるレプリケーションの負荷も極めて低いものになります。スケールアップするためには，ただ単にマシンを追加すればいいのです。
一方で Stefan Tilkov 氏は，REST とステートを次のように定義する。
まず第一に，REST はステートレスの考え方を持ってはいますが，それは機能を提供するアプリケーションがステートを保持できないという意味ではない，という点が重要です – もしそういう意味であったなら，すべてのアプローチが大部分のシナリオにおいて役に立たないものになってしまうでしょう。REST においては，ステートはリソースのステートに転化されるか，あるいはクライアント上で保持されなければなりません。別の言い方をするなら，サーバは通信を行うすべてのクライアントに対して，ひとつの要求処理を越えて何らかの通信状態を維持する必要がないのです。この理由として最も明確なのはスケーラビリティです – もしサーバがクライアントの状態を保持する必要があるならば，通信対象のクライアント数がサーバのフットプリントに重大な影響を及ぼすでしょう (これには通常，ある程度の再設計を要することに注意してください – 単純に URI をあるセッションステートに保持して，それを RESTful に呼び出すというものではありません)。 しかしその他にも，さらに重要である可能性のある面があります – ステートレスという制約によって，２つの連続する要求が同じサーバで処理されているという前提は機能しなくなり，サーバの変更からクライアントが切り離されるという点です。クライアントがサーバから受け取ったドキュメントには，サーバからのリンクが含まれているかも知れませんし，何らかの処理を行っている間にサーバがシャットダウンされ，ハードディスクが交換され，ソフトウェアが更新された上でリスタートするかも知れません – そしてもし，クライアントがサーバから受け取ったリンクのひとつをたどった場合でも，その事実に気づくことはないのです。
Ganesh はステートレス性がスケーラビリティやリカバリの面で好ましい理由については理解している。それでもなお，氏はこの側面について疑問を持ち，本来ならば分散インフラストラクチャで処理すべきものをアプリケーション層にまで押し上げ過ぎているのではないか，と考えている。
アプリケーションのドメイン特有の要素としては適切なアプローチだと思います。しかし，サービス品質 (信頼性のためのメッセージシーケンス番号，あるいはセキュリティ面でのセッションキーなど) を提供する上で有用な，セッションステートフルな要素を持つドメイン中立なクラスもまた存在します。REST なプロトコルがこのような機能のサポートを拒否することは，統一的な形式でサービス品質を提供する能力を損ねています […]。そのために REST では，サービス品質はアプリケーションの責任となっています。それが私にはいつも，プロトコル実装としていささかの責任逃避とも思えるのです。
しかし Ganesh が関心を向けているのは，Bill と Stefan が自身の記事で言及している形式のステート，つまりセッションステートの方だ。記事によれば，この問題に対して NoSQL がスケーラブルで耐障害性を備えたソリューションを提供するのだという。Ganesh は Redis の実装を例題として説明をしているが，おそらくはほどんど (すべて？) の NoSQL 実装でも同じことだろう。
セッションステートをメモリ上よりも Redis のような NoSQL データベースに格納する方法が，ベストプラクティスとして推奨されるようになってきています。単純なステートレスファームとしてのサーバ群が共有セッションステートとしての NoSQL データベースにアクセスする，という意味において，このようなセッションストレージの委任方式は，これまでのセッション対応クラスタに代わるものです。Redis において特徴的なのは，GET および SET 操作の複雑性が Order(1)，すなわち固定時間であるという点です。これは (少なくとも理論上は) Redis データベースを使用すればパフォーマンスに影響を与えることなく，サーバの数を無制限に増やすことが可能である，という意味になります。
記事では続けて Ganesh の考えている，セッションコンテキスト状態を管理するために Redis (NoSQL) データベースを用いる方法が，ステートフルな REST アプリケーションを今や真剣に検討する必要がある (そしておそらくは REST の原則を，場合によっては拡張を通じて更新する必要がある) ことを意味している，と説明する。最後に氏は，次のように締めくくる。
スケーラブルな [NoSQL] セッションストレージを使用して REST ベースの処理に安全性と信頼性を提供できるよう，標準およびドメイン非依存な機構が拡張されることが望まれています。
成功したソフトウェア開発方法論，フレームワーク，標準の大部分は，新たなアプローチと経験の獲得に伴う発展によってその妥当性を維持している。REST が最初に提案されたときには，NoSQL は学術的研究でさえなく，ましてその実装がさまざまな業務環境で用いられるというものではなかった。そこでひとつの疑問が生じる – REST は NoSQL によって発展する必要があるのだろうか，あるいはステートレス性は実装やステートを保存するために利用可能なアプローチとは関わりのない要件なのだろうか？