Arnon Rotem-Gal-Oz氏は新しい記事「CRUDはRESTにとって良くない」の冒頭で次のように主張している。
表面的に見れば、きわめてぴったりと合っているように見えますが（技術的にもアーキテクチャ的にも）、ふたを開けてみればどちらの意味でも合っていないことが分かるでしょう。
今日、RESTアーキテクチャスタイルのもっとも一般的な実装はHTTPに準拠しており、したがってHTTPの操作メソッドすなわちPOST、GET、PUT、DELETEに準拠していることになる。一般的な実装ではこれらの操作メソッドをCRUDの用語、つまり、Create、Read、Update、Deleteに紐付ける。この際の典型的なマッピングは１対１で行われる。
- GETは典型的にCRUDのReadに紐付けられる。ただし、GETはSELECT（Read）との革新的なマッピングということを越えた機能をいくつか備えている。
- DELETEは典型的にCRUDのDeleteに紐付けられる。
- PUTは典型的にCRUDのUpdateに紐付けられるが、いくつか注意点がある。
- PUTがリソースの完全な置き換えを要求するのに対して、Updateは部分的な更新も可能である。
- PUTはリソースをCreateするのにも使用できる（URIがクライアントによって設定された場合）。
- POSTは典型的にCRUDのCreateに紐付けられるが、子リソースの生成しかサポートしていない。POSTはまたリソースの部分的な更新にも用いることができる。
Rotem-Gal-Oz氏は次のように主張する。
HTTPの操作メソッドはデータベース指向であるよりはむしろドキュメント指向です。だからリソースの更新、削除あるいは新しいリソースの追加を行うことはできますが、その方法はデータベース的な意味におけるCRUDと正確には一致していません。すくなくともHTTP操作メソッドの利用に関してはそうなります。
しかしCRUDがRESTにとっての適切なパラダイムではない最大の理由は、アーキテクチャに起因するものだ。RESTの中心にあるのは、ハイパーメディアを用いたプロトコルステートマシンの実装である。Rotem-Gal-Oz氏はTim Ewald氏を引用する。
（前略）分かってきたのは次のことです。あらゆるコミュニケーションプロトコルにはステートマシンがあります。これは、いくつかのプロトコルではきわめて単純ですが、他のものではもっと複雑なこともあります。RPCによってあるプロトコルを実装する際には、コミュニケーションのステートを変更するメソッドを開発します。このステートはエンドポイントにおいてはブラックボックスとして保持されます。このようにプロトコルステートが隠蔽されているせいで、間違いが容易に起こります。例えば、「初期化」の前に「実行」を呼んでしまうかもしれないという具合に。このような問題を避けるため、インターフェイスの型情報に注釈をつけることが長らく検討されてきましたが、私自身は主流の解決策について詳しくありません。また、プロトコルのステートが、そのステートを変更するメソッド呼び出しの背後に明快ではないやり方でカプセル化されることで、バージョニングも興味深いものになります。
RESTの本質はプロトコルのステートを明らかにし、URIによってアドレス指定を可能にする点にあります。プロトコルステートマシンの現在のステートを表すのは、現在の操作対象となっているURIと検索されたステートの表現です。ステートの変更は、移動先ステートのURIを操作することによって行い、それを新しいステートとします。あるステートの表現は他のステートへのリンク（グラフにおける矢印）を含んでおり、それによって現在のステートから行き来することができます。これこそがブラウザベースのアプリケーションの動作形態なのであり、あなたが作るアプリケーションのプロトコルがこのやり方で機能できない理由は何もないのです。（ATOM Publishing protocolが規範的な例ですが、これはエンティティに関するもので、ステートマシンに関するものではないと思われがちです。）
John Evdemons氏の記事では、なぜCRUD的なサービスがSOAのアンチパターンであるのかが説明されているが、その記事に従ってRotem-Gal-Oz氏はCRUD型RESTの欠点を説明する。
- 「サービス」というものについての全体構想を避けています。ビジネスロジックが一切ないのですから。
- 外部に見せているのは内部的なデータベース構造ないしデータであって、考え抜かれた契約ではありません。
- 本当のサービスを迂回して直接データにアクセスすることを助長します。
- Blobサービス（データソース）を生み出します。
- 極小の半サービス（前述したBlobに関する複数の「インターフェイス」）を助長しますが、このようなサービスは分散コンピューティングに関するいくつかの誤謬を軽視したものです。
- 羊の皮をかぶったクライアント－サーバでしかありません。
Rotem-Gal-Oz氏は記事の最後において、再度次のように強調している。単にHTTP、XML、JSONといった標準を適用するだけでは（有用かもしれないけれども）RESTにはならない。RESTアーキテクチャを適用して初めてRESTになるのである。
RESTはSOAと同じように、標準と一般的なAPIの集合体ではなく、アーキテクチャ上のパラダイムであって、そのパラダイムを理解し、そこに従う必要があるのだ。この記事はそれを思い出させてくれる重要なものである。