RESTとCRUDの違い

RESTを学びましたが、CRUDによく似ています（CRUDについて読んだことから）。

私はそれらが異なっていることを知っています、そして、それらが似ていると思うことは私がそれらを理解しないことを意味するのだろうか。

RESTはCRUDの「スーパーセット」ですか？CRUDでできることはすべてありますか？

驚いたことに、他の回答では、RESTとCRUDの本当の違いと考えられるもの、つまりそれぞれが管理しているものがわかりません。

CRUDは、データリポジトリで実行される基本操作を意味します。レコードまたはデータオブジェクトを直接処理します。これらの操作とは別に、レコードは受動的なエンティティです。通常、データベーステーブルとレコードだけです。

一方、RESTはリソース表現で動作し、各表現はURLで識別されます。これらは通常、データオブジェクトではなく、複雑なオブジェクトの抽象化です。

たとえば、リソースはユーザーのコメントにすることができます。つまり、「コメント」テーブルのレコードだけでなく、「ユーザー」リソースとの関係、コメントが添付されている投稿、応答する別のコメントも意味します。

コメントの操作は基本的なデータベース操作ではありません。元のポスターへのアラートの発動、ゲームのような「ポイント」の再計算、「フォロワーストリーム」の更新など、重大な副作用が生じる可能性があります。

また、リソース表現にはハイパーテキストが含まれており（HATEOASの原理を確認）、設計者はリソース間の関係を表現したり、操作のワークフローでRESTクライアントをガイドしたりできます。

要するに、CRUDは（主にデータベースと静的データストレージ用の）セットプリミティブ操作であり、RESTは（主にWebサービスと他の「ライブ」システム用の）非常に高レベルのAPIスタイルです。

1つ目は基本データを操作し、もう1つは複雑なシステムと対話します。

まず第一に、両方とも単に一般的なイニシャルです。彼らは恐れることは何もありません。

さて、CRUDは、それが多くのアプリケーションで共通の特徴だし、それは言う方が簡単ですので、省略したシンプルな用語であるCRUDを。データ（またはリソース）で実行できる4つの基本操作について説明します。作成、読み取り、更新、削除。

ただし、RESTは（AJAXのような）名前付きのプラクティスであり、それ自体はテクノロジーではありません。HTTPプロトコルに長い間備わっていたが、めったに使用されない機能の使用を推奨します。

URL（Uniform Resource Locator）があり、ブラウザでアドレス行を指定すると、HTTPリクエストが送信されます。各HTTPリクエストには、サーバーがリクエストを発行したクライアントに返信するHTTPレスポンスを知るために使用できる情報が含まれています。

各リクエストにはURLが含まれているため、サーバーはアクセスするリソースを認識していますが、methodを含めることもできます。メソッドは、そのリソースをどうするかを説明します。

しかし、この「方法」の概念はあまり使用されませんでした。

通常、人々はGETメソッドを介してページにリンクし、POSTメソッドを介してあらゆるタイプの更新（削除、挿入、更新）を発行します。

そのため、1つのリソース（URL）自体を真のリソースとして扱うことはできません。同じリソースを削除、挿入、または更新するには、個別のURLが必要でした。例えば：

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

REST を使用すると、POSTとは別に他のHTTPメソッドを使用するため、よりスマートなフォームを作成し、URLだけでなくメソッドを区別できるようにサーバーをプログラムします。たとえば、次のとおりです。

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

単一のURLが単一のリソースを記述することを忘れないでください。単一の投稿は単一のリソースです。RESTを使用すると、リソースは処理されるはずの方法で処理されます。処理するリソースとその処理方法をサーバーに伝えます。

「RESTfulアーキテクチャ」には他にも多くの機能があり、興味があればウィキペディア、他の記事、または本で読むことができます。一方、CRUD自体はそれほど多くありません。

RESTは「代表的な状態転送」の略で、システム内のリソースの状態を通信および変更することを意味します。

RESTが非常に複雑になるのは、RESTの背後にある理論が、リモートシステム上の情報を管理するためにメディア、ハイパーメディア、および基盤となるプロトコルを活用するためです。

一方、CRUDは、データベース内のデータに必要な一般的な操作のニーモニックです。作成、取得、更新、削除。しかし、それ以上深くはなりません。

それがあなたの質問への答えですが、RESTとCRUDが一緒に議論されるときに見られるよくある間違いについて言及します。REST over HTTPはGET PUT POSTおよびDELETEを提供し、CRUDはCREATE RETRIEVE UPDATE DELETEを提供するため、多くの開発者はRESTをCRUDに直接マップしたいと考えています。REST動詞をCRUD操作に直接マップしたいのは自然なことです。

ただし、HTTPは「作成または更新」スタイルを使用し、CRUDは作成と更新を分離します。そのため、2つ（！）の間のクリーンで一般的なマッピングを作成することはできません（！）

GETとDELETEは簡単です... GET ===取得、DELETE === DELETE。

しかし、HTTP仕様によると、PUTは実際には作成および更新です。

• PUTを使用して、識別子を含む、オブジェクトに関するすべてを知っているときに、新しいオブジェクトを作成します

• PUTを使用してオブジェクトを更新します（通常、オブジェクトの完全な表現で）

POSTは「処理」動詞であり、「追加」動詞と見なされます。

• POSTを使用して、新しいオブジェクトをコレクションに追加します（つまり、新しいオブジェクトを作成します）

• HTTP仕様では「データ処理」動詞として定義されているため、他の動詞がまったく当てはまらない場合にもPOSTが使用されます。

• チームがPOSTでハングアップする場合は、WWW全体がGETおよびPOSTで構築されていることに注意してください;）

そのため、RESTとCRUDには類似性がありますが、ほとんどのチームが犯す間違いは、両者を同等にすることです。REST APIを定義するとき、CRUDニーモニックにこだわらないように、チームは本当に注意する必要があります。RESTには、実際にはCRUDにきれいにマッピングされない追加の複雑さがたくさんあるためです。

CRUDは、データの読み取りと書き込みのための基本的なストレージ動詞の最小限のセット（作成、読み取り、更新、削除）を指定します。次に、これらを集約することにより、他の操作を構築できます。これらは通常、データベース操作と見なされますが、データベースと見なされるものは任意です（たとえば、リレーショナルDBMSでもYAMLファイルでもかまいません）。

RESTは通常「アーキテクチャスタイル」であり、通常、CRUD操作およびその他のより高いレベルの操作が含まれ、すべて「リソース」の概念で実行されます（任意ですが、これらはアプリケーションのエンティティです）。RESTには、興味深い（そして特にHTTPとペアになっている）一連の制約があります。

RESTインターフェースは、特定のリソースに対するすべてのCRUD操作を公開できますが、必須ではありません。RESTインターフェースで利用できるものは任意であり、システムの許可、UIの考慮事項、およびインターフェースが設計および作成された日にどれだけ暑かによって変わる可能性があります。暑い日は、通常、よりミニマリストなインターフェイスにつながりますが、通常は逆の場合もあります。

CRUD

• CRUDは、作成、読み取り、更新、削除という4つの基本的なSQLコマンドタイプです。
• ほとんどのアプリケーションには、何らかのCRUD機能があります
• CRUDアプリケーションは、フォームを使用してデータベースにデータを出し入れするアプリケーションです。

残り

• RESTはRepresentational State Transferの略です（「ReST」と綴られることもあります）。

• これは、ステートレスで、クライアントサーバー、キャッシュ可能な通信プロトコルに依存しています。事実上すべての場合、HTTPプロトコルが使用されます。

• RESTは、ネットワークアプリケーションを設計するためのアーキテクチャスタイルです

RESTはマシンのWebページのようなものであり、マシンはブラウジングできますが、CRUDはSOAPのようなものであり、クライアントと強く結びついています。これらが主な違いです。Ofc。表面上は似ていますが、CRUDは基本的なエンティティ操作を記述しますが、RESTは任意のアプリケーションのインターフェースを記述できます。RESTが4つのHTTPメソッドをより多く使用できるという別の違い。すべての違いを収集したい場合は非常に長い答えになります。RESTとSOAPに関する質問を確認すると、ほとんどの違いが見つかります。

RESTをCRUDと混同することは非常によくある間違いであり、その原因は開発者がRESTについて詳しく読む時間がないことです。彼らは、同様の開発者によって書かれた限られたCRUDスタイルの例に基づいて、それを理解せずに使用したいだけです。例とチュートリアルの大部分は、知識の深刻な不足を反映しています。RESTリソースをエンティティにマッピングし、HTTPメソッドをこれらのエンティティのCRUD操作にマッピングし、ハイパーリンクなしでRESTを使用することは、その兆候です。RESTにより、ハイパーリンク（POST / PUT / DELETE / PATCHメソッドを含むリンクを含む）を操作にマッピングし、（通常はAPI固有の）リンク関係を確認することでクライアント側の操作を識別します。RESTクライアントがリンク関係とは何かを知らず、HTTPメソッドと一部のURIテンプレートのみを知っている場合、それはRESTクライアントではなく、HTTPクライアントのCRUDです。RESTクライアントがブラウザーで実行される単一ページのjavascriptアプリケーションであるというもう1つのよくある間違い。もちろん、このようなクライアントを実装できますが、RESTは主に自動クライアント（知らない開発者によって作成されたサーバー側アプリケーション）を対象としており、手動クライアント（ユーザーが作成したユーザー制御ブラウザーアプリケーション）を対象としていません。ブラウザークライアントが1つしかないということは、RESTが本当に必要ではなく、プロジェクトをオーバーエンジニアリングしただけの兆候かもしれません。これらの場合、CRUD APIは実行可能なソリューションであり、開発者はこれらのCRUD APIをRESTとして呼び出しています。違いを知らないためです。もちろん、このようなクライアントを実装できますが、RESTは主に自動クライアント（知らない開発者が作成したサーバー側アプリケーション）を対象としており、手動クライアント（ユーザーが作成したユーザー制御ブラウザーアプリケーション）は対象としていません。ブラウザークライアントが1つしかないということは、RESTが実際に必要ではなく、プロジェクトを過剰に設計したことを示している可能性があります。これらの場合、CRUD APIは実行可能なソリューションであり、開発者はこれらのCRUD APIをRESTとして呼び出しています。違いを知らないためです。もちろん、このようなクライアントを実装できますが、RESTは主に自動クライアント（知らない開発者が作成したサーバー側アプリケーション）を対象としており、手動クライアント（ユーザーが作成したユーザー制御ブラウザーアプリケーション）は対象としていません。ブラウザークライアントが1つしかないということは、RESTが実際に必要ではなく、プロジェクトを過剰に設計したことを示している可能性があります。これらの場合、CRUD APIは実行可能なソリューションであり、開発者はこれらのCRUD APIをRESTとして呼び出しています。違いを知らないためです。