REST vs CRUD: 主な概念と違い

CRUD と REST は、アプリケーション プログラム インターフェイス (API) 業界で最も人気のある 2 つの概念です。

残酷 作成、読み取り、更新、削除の略で、データの管理に重点を置いています。 

REST、または Representational State Transfer は、クライアントとサーバーがどのように対話および通信するかに焦点を当てた Web サービスを設計する方法です。 

どちらもデータベースのデータを操作するため、人々が混乱するのも当然です。このブログでは、REST と CRUD とは何か、それらを支配する基本原則、そしてそれらの類似点と相違点について説明します。

主要な取り組み

REST はステートレスなクライアントとサーバーの相互作用を可能にし、キャッシュと統一されたインターフェースによって効率を高めます。

CRUD は、作成、読み取り、更新、削除の略で、データベース管理に由来します。

REST はより広範囲で、HTTP を介したデータ操作の標準を提供しますが、CRUD はレコードの維持に特化しています。

REST API には CRUD 操作を含めることができますが、REST は CRUD を超えた多くの機能を提供します。

RESTとは何ですか？ 

RESTは、Representational StateTransferの略語です。 これは、システムがどのように相互作用するかを指示する、Web上のコンピューターの標準を提供するソフトウェアアーキテクチャスタイルです。 ロイフィールディングRESTプロトコルの創設者である、は、RESTプロトコルを「分散ハイパーメディアシステム内のアーキテクチャ要素の抽象化」と定義しています。 

RESTの起源

2000年にRESTプロトコルがリリースされる前は、Web開発者はWeb APIを開発する方法、またはWebAPIを使用する方法についての標準を持っていませんでした。 当時は多くのプロトコルが使用されていましたが、それらは面倒で複雑すぎて実行できませんでした。 Roy Fieldingは同僚と協力してこの問題に対処しようとし、今日RESTプロトコルとして知られているものを開発しました。 RESTの開発により、XNUMX台のサーバーが世界中でデータを交換できるようになりました。 

REST準拠のシステムは RESTful システム。これらのシステムは、ステートレスであることと、クライアントとサーバーの懸念が分離していることが特徴です。2000 年の開始以来、eBay や Amazon などの多くの企業が REST プロトコルを使用しています。 

RESTの5つの基本原則 

REST は 5 つの基本原則に基づいて動作します。

1. 独立したクライアント・サーバー間のやりとり

残り クライアントとサーバーの独立した実装を可能にします。 この独立性は、両方の当事者がお互いを知らずに、または相互作用することなく変更を加えることができることを意味します。 サーバーとクライアントが何であるかを定義することは、この原則を理解するための最初のステップです。 

• サーバー： 簡単に言えば、サーバーとは他のデバイスにサービスを提供する機械です。 さまざまな種類のサーバーブート サーバー、データベース サーバー、プリント サーバー、特定のアプリケーション専用のサーバーなどです。さまざまなアプリケーションが、サービスを提供するために他のアプリケーションに依存しています。たとえば、検索エンジンは情報を Web サーバーに送信します。一方、ネットワーク上のプリンターは、結果を生成するために情報をプリンター サーバーに送ります。 
• クライアント： クライアントは、サーバーのサービスを使用するリモート システムです。サーバーに接続されているすべてのマシンはクライアントと呼ばれます。一部のクライアントはディスク容量が限られているため、機能するためにリモート ファイル システムに依存しています。一部のデバイスは、同時にクライアントとサーバーの両方になることができます。 

REST プロトコルにより、2 つのシステムは結果に影響を与えることなく独立して動作できます。クライアントとサーバーがメッセージを送信するときに使用する形式を認識している限り、異なるクライアントは最終的に同じ REST エンドポイントに到達します。クライアントとサーバーのインターフェイスが分離されているため、両方のシステムを独立して進化させることもできます。 

2. REST APIにおけるステートレス通信

RESTful APIは、クライアント側で行われたHTTPリクエストについて何もキャッシュしません。 キャッシュしないということは、サーバーがすべてのセッションを新しいものとして扱い、サーバーに保存されている以前の情報を利用できないことを意味します。 真にあるために ステートレス、サーバーは、同じクライアントによる以前のセッションの認証の詳細を保存しません。 REST APIはステートレスであるため、サーバーがタスクを完了できるようにするには、クライアントはセッションごとに必要なすべての情報を提供する必要があります。 

3. キャッシュによる効率化 

サーバー上のリクエストは、さまざまな経路またはキャッシュを通過します。これらのキャッシュは、ローカル キャッシュ、プロキシ キャッシュ、またはリバース プロキシのいずれかであり、RESTful API サーバーは情報をキャッシュ可能またはキャッシュ不可能としてマークできます。クライアントがエンド リクエストを送信すると、このリクエストは一連のキャッシュを通過します。そのパス上のいずれかのキャッシュに表現の最新のコピーがある場合は、そのキャッシュを使用して結果が生成されます。どのキャッシュもリクエストに対応できない場合は、元のサーバーに戻ります。RESTful API サーバーは、情報がキャッシュ可能かキャッシュ不可能かを判断します。 

キャッシングにはいくつかの利点があり、そのうちのいくつかは次のとおりです。

• 帯域幅を削減
• メモリからデータを取得するためにサーバーとやりとりする回数を減らすことで、レイテンシを短縮します。
• サーバー負荷を軽減
• ネットワーク障害の減少

4. 統一されたインターフェースによる予測可能なインタラクション 

REST API を利用するシステムでは、クライアントとサーバーが予測どおりに対話します。システム内のリソースは、1 つの論理 Uniform Resource Identifier (URI) のみに従います。RESTful API と非 REST API の違いは、使用するデバイスやアプリケーションに関係なく、このインターフェイスが統一されていることです。REST API のリソースは、Hypermedia as the Engine of Application State (HATEOAS) を使用して、該当する場合はいつでも関連情報を取得します。RESTful API のすべてのリソースは、命名規則とリンク形式に関する特定のガイドラインに従います。統一されたインターフェイスは、次の 4 つの基本原則に従います。

• リソースベース: 各リソースは、リソース識別子として URI を使用します。
• 表現によるリソースに対するアクション: メタデータに関連付けられたリソースには、変更または削除できるサーバー上の情報が含まれています。
• 自己記述型メッセージ: 各メッセージには、その処理方法を説明するすべての情報が含まれています。
• アプリケーション状態のエンジンとしてのハイパーメディア (HATEOAS): クライアントは、本文コンテンツ、要求ヘッダー、および URI によって状態を提供し、サービスは、応答コード、応答ヘッダー、および本文コンテンツによって顧客に状態を提供します。これをハイパーメディアと呼びます。

5. スケーラビリティのための階層化アーキテクチャの活用

RESTful APIは、結果を提供するために階層化されたシステムに依存しています。このアプローチにより、開発者はシステムをモジュール化できます。たとえば、OpenAPIを使用してカスタムTerraformプロバイダーを作成してAPI管理を効率化する方法をご覧ください。この階層化されたシステムは、割り当てられたレイヤーを超えてレイヤーが見えないという制限を設け、開発者が さまざまな機能をさまざまなサーバーに展開します。 各レイヤーは独立して動作し、各レイヤーは自身のレイヤー以外の他のレイヤーの機能を認識しません。ユーザー側では、階層化システムでは通常、プライマリ サーバーに接続しているのか、中間サーバーに接続しているのかを区別できません。中間サーバーの重要性は、負荷分散キャッシュ共有を提供できることです。

「スケーラブルで効率的な Web サービスを構築するには、CRUD と REST の両方を習得することが不可欠です。」

CRUD とは: データ管理の基礎

CRUDはCREATE、READ、UPDATE、DELETEの頭文字をとったものです。 XNUMX つのデータベース コマンド CRUDの基盤です。 この頭字語はプログラマーの間ではよく知られていますが、多くのソフトウェア開発者は、CRUD が API を作成するための最新の方法として作成されたものではないため、より多くのガイダンスと見なしています。 結局のところ、その起源はデータベースにあります。 その定義によれば、それは建築システムというよりもサイクルです。

多くのプログラミングプロトコルと言語には、異なる名前と若干の機能の違いを持つ独自のCRUDバージョンがあります。良い例は、挿入、選択、更新、削除を使用するSQL（構造化クエリ言語）です。. また、動的な Web サイトには、あらゆる e コマース サイト (Amazon、Mango など) の購入者などの CRUD サイクルがあります。ユーザーはアカウントを作成したり、情報を更新したり、ショッピング カートから商品を削除したりできます。CRUD フレームワークを使用する他のプログラミング言語には、Java (JOOQ、iBAtis)、Phyton (Django)、PHP (Propel、Doctrine)、.NET (NHibernate、LLBLGEN Pro) などがあります。

CRUD の簡単な歴史

CRUDの頭字語は、構造化クエリ言語（SQL）で使用されるデータベース機能を説明するために1980年代に作成されたと考えられています。この用語は、1983年の本で初めて知られるようになりました。 データベース環境の管理 CRUD操作についての最初の言及は、1990年の記事「セマンティックからオブジェクト指向データモデリングへ” （ハイム・キロフ著） 

CRUD サイクルは、データベースの永続ストレージを強化するための一連の関数として設計されました。データベースは、多くの場合、それを開始したプロセスよりも長く存続します。現代のソフトウェア プログラミングと開発では、CRUD は関数として始まった段階を超え、SQL、DDS、HTTP プロトコルなどのアプリケーションの設計原則に役立っています。

CRUDの4つの基本操作

上で説明したように、CRUD サイクルの 4 つの基本的な操作は、CREATE、READ、UPDATE、および DELETE です。

• 作成： 1 つ以上のエントリを追加します。これは、SQL の Insert 関数に相当します。
• 読みます： さまざまな基準に基づいてデータを取得し、SQL の Select 関数と同等です。
• UPDATE： 上書きせずに手順を変更し、レコードを修正します。 
• DELETE： 指定された 1 つ以上のエントリを削除します。 

LとS：CRUDへの追加

CRUDはLISTINGを含むように拡張されることもある （クルドル）リストは、ページ区切りを使用せずに、より広範なデータが簡単なメモリ ストレージに保存されるのを防ぐのに役立ちます。 

一部のプログラマーはCRUDにSを追加します （スクルド） 検索用。データ取得は更新と削除にのみ使用されますが、ソフトウェアアプリケーションのユーザーは、検索結果のリストを表示するためにデータベースでデータを検索する必要がある場合があります。

REST と CRUD のセキュリティに関する考慮事項

API により、アプリケーションはネットワークやインターネットを介して接続および通信できるようになります。REST および CRUD システムは API であるため、アプリケーションが効果的に保護されていない場合、これらのプラクティスによって脆弱性が生じる可能性があります。これらのプラクティスを実装すると、どの API メソッドを選択しても、アプリケーションのセキュリティのギャップを埋め、セキュリティを強化するのに役立ちます。

認証と承認

認証要件を実装して、許可されたユーザーのみがデータにアクセスできるようにします。0Auth2 フレームワークは、REST 原則を利用するアプリケーションやサービスに適していますが、ロールベースのアクセス制御は CRUD 対話に最適です。

データ検証

すべてのデータ入力がファイルの種類や形式などの特定の基準を満たしていること、およびシステムが処理前に潜在的に有害なデータを削除することを確認するためのプロトコルを実装します。 

Encryption

データを転送するときは安全な HTTP (https) を使用し、保存されたデータを暗号化して、権限のないユーザーがアクセスしたり表示したりできないようにします。

レート制限

API が過負荷になるのを防ぎ、どのクライアントもリソースの共有を利用しないようにするために、各クライアントが利用できるリクエストの数を制限します。レート制限は、API リクエストをゲートキーピングすることで、サーバーをサービス拒否 (DoS) 攻撃から保護するのにも役立ちます。

RESTとCRUDの実装例 

理解を深めるために、CRUD 操作と RESTful サービスがどのように実装されているかを見てみましょう。

SQL を使用した CRUD の例

-- Insert a new user into the 'users' table
INSERT INTO users (name, email) VALUES ('John Doe', '[email protected]');

-- Select a user from the 'users' table where the ID is 1
SELECT * FROM users WHERE id = 1;

-- Update the email of the user where the ID is 1
UPDATE users SET email = '[email protected]' WHERE id = 1;

-- Delete a user from the 'users' table where the name is 'John Doe' and the email is '[email protected]'
DELETE FROM users WHERE name = 'John Doe' AND email = '[email protected]';

上記の例のグラフィックを使用すると、グラフィックで概説されている CRUD 手順は、SQL を使用して次の機能を実行します。

• 創造する: このステップでは、コマンドはデータベースのユーザーテーブルにJohn Doeという名前の新しいレコードを挿入し、電子メールアドレスは [メール保護].
• 読む: このコマンドは、SQL テーブルの id 列の値が 1 であるユーザー テーブルから表示するレコードを取得します。
• 更新: この行は、レコードの「メール」列の「id」値が1の情報をメールアドレスで上書きします。 [メール保護]. 
• 削除: このコマンドは、同じ電子メール アドレスで名前が「John Doo」として入力された誤ったレコードをデータベースから削除します。

HTTP メソッドを使用した REST の例

# Create a new user (POST request)
POST /users
{
  "name": "John Doe",
  "email": "[email protected]"
}

# Retrieve user information by ID (GET request)
GET /users/1

# Update user information (PUT request)
PUT /users/1
{
  "email": "[email protected]"
}

# Delete a user by ID (DELETE request)
DELETE /users/1

上記の例の図では、これらの REST コマンドは次のタスクを実行します。

• POST: POST /usersリクエストは、名前値が「John Doe」、電子メール値が「[メール保護]に設立された地域オフィスに加えて、さらにローカルカスタマーサポートを提供できるようになります。」
• PUT: PUT /users/1 リクエストは、IDが1のインシデントのメール値を「[メール保護]この例では、John Doe レコードの ID が 1 であると想定しています。

REST と CRUD の実際の使用例

エンジニアは REST-CRUD の組み合わせで 2 つのシステムを一緒に使用することがよくありますが、アプリケーションやサービスを構築する際の実際の使用においては、それぞれに独自の長所があります。

REST は、クライアントとステートレス サーバー間のやり取りを目的としています。この概念は、ソーシャル メディア アプリケーション、ストリーミング サービス、オンライン バンキングなどのパブリック API に適しています。REST は、マイクロサービスやモノのインターネット (IoT) アプリケーションなどの相互運用可能なシステムの開発にも最適です。

CRUD は、シンプルな CMS エディター、インタラクティブなカレンダー、イベント管理アプリケーションなどの基本的なデータ管理アプリケーションに適しています。また、管理ダッシュボードや在庫管理システムなどの内部アプリケーションを含む、直接的なデータ操作を必要とするアプリケーションやツールの構築にも最適です。 

「CRUD はデータ操作に重点を置いていますが、REST は Web サービスの通信方法を定義します。」

CRUD と REST の類似点は何ですか?

純粋主義者の中には、REST と CRUD はまったく関係がないと主張する人もいるかもしれません。しかし、それらのコマンドを詳しく調べると、類似点が明らかになります。

RESTコマンド

• POST: データベースに新しいレコードを作成します。
• GET: このリクエストは、データベースから取得した情報を読み取ります。
• PUT/PATCH: オブジェクトを更新します。
• DELETE: データベースからレコードを削除します。

CRUDコマンド

• CREATE: INSERT ステートメントを通じて新しいレコードを作成します。REST では、これは POST コマンドです。 
• READ/RETRIEVE: これらの手順は、入力パラメータに基づいてデータを取得します。REST では、これは GET コマンドに相当します。
• UPDATE: データを上書きせずに更新します。REST では、これは PUT リクエストです。
• DELETE: データベースからデータを削除します。REST は同じリクエストを使用してデータを削除します。

CRUD と REST の違いは何ですか?

REST と CRUD は似ているため、同じ機能を持つと誤解されがちです。しかし、それは真実とは程遠いものです。もう少し深く掘り下げて、その違いを探ってみましょう。 

• REST は、HTTP コマンドを使用するリソースとハイパーメディアを中心としたアーキテクチャ システムです。CRUD は、データベース設定でレコードを維持するためのサイクルです。基本形式では、CRUD は情報を操作し、アプリケーションの機能を記述する方法です。REST は、HTTP コマンドを通じてデータを制御する方法です。これは、ユーザー向けの情報を作成、変更、および削除する方法です。 
• CRUD 関数は REST API 内に存在することができますが、REST API は CRUD 関数に限定されません。CRUD は REST アーキテクチャ内で動作できますが、REST API は CRUD とは独立して存在できます。たとえば、REST API を使用すると、CRUD 関数に対応していなくても、クライアントがサーバーを再起動できます。REST は、適切な HTTP メソッドを使用している限り、これを実行できます。 
• REST は通常、HTTP コマンドを通じてデータを使用することを指します。これは、ユーザーが画面上でデータを操作し、その情報をサーバー上に保存する方法を容易にする教義です。プログラマーは、基本的な CRUD 機能を処理できる REST API を作成できますが、その逆は言えません。 
• REST と CRUD の機能は似ていますが (上で説明したとおり)、同じではありません。PUT は、まだ存在しないリソースであっても、リソースを置き換えます。POST は新しいリソースを追加します。どちらのコマンドも新しいリソースを作成しますが、PUT は通常、既存のリソースを更新するために使用されます。PATCH は主にリソースの一部を更新するために使用されますが、PUT はリソース全体を置き換えて更新する場合にのみ使用されます。 

RESTとCRUDは連携して動作しますが、同じものではありません

REST と CRUD は連携して動作します。CRUD は REST 環境内に存在でき、その機能は互いに対応していることが多いのですが、同じではありません。両者を区別する最も良い方法は、REST が標準 (API アーキテクチャ) であり、CRUD が機能であることを覚えておくことです。この重要かつ単純な違いを理解することは、両方を理解するために必要です。 

LogicMonitorの アプリケーションパフォーマンス監視 (APM) プラットフォームを理解し、REST および CRUD API を最大限に活用する方法を学びます。