Різниця між REST та CRUD


168

Я дізнався REST, і це дуже схоже на CRUD (з того, що я читав про CRUD).

Я знаю, що вони різні, і мені цікаво, якщо думати, що вони схожі, значить я їх не розумію.

Це те, що REST - це «суперсеть» CRUD? Чи все, що CRUD робить і багато іншого?


17
Якщо ви думаєте, що вони схожі, це означає, що ви їх розумієте. Читаючи відповіді, я бачу дивно і те , що я вважаю некоректним рівень НЕ визнає схожість між цими поняттями. Я вважаю, що правильний спосіб зрозуміти REST - це думати про це як "CRUD для HTTP-ресурсів". Якщо ви розумієте, що таке ресурс HTTP (очевидно, що це не так, як запис бази даних), і ви знаєте, що таке CRUD, то опис REST як "CRUD для HTTP-ресурсів" - це правильний і стислий спосіб передати суть REST.
Джейсон Лайвсі

Відповіді:


205

Дивно, але в інших відповідях я не бачу того, що вважаю реальною різницею між REST та CRUD: чим управляє кожен.

CRUD означає основні операції, які потрібно виконати в сховищі даних. Ви безпосередньо обробляєте записи або об’єкти даних; крім цих операцій, записи є пасивними сутностями. Зазвичай це просто таблиці баз даних і записи.

REST, з іншого боку, працює на представленнях ресурсів, кожне з яких ідентифікується URL-адресою. Зазвичай це не об'єкти даних, а складні об'єкти абстракцій.

Наприклад, ресурс може бути коментарем користувача. Це означає не лише запис у таблиці "коментарів", але і його зв'язки з ресурсом "користувача", повідомлення, до якого додається коментар, можливо, ще один коментар, на який він відповідає.

Операція над коментарем не є примітивною операцією з базою даних, вона може мати значні побічні ефекти, такі як запуск попередження на оригінальний плакат, або перерахунок деяких ігрових "точок" або оновлення деяких потоків послідовників.

Також представлення ресурсів включає гіпертекст (перевірити принцип HATEOAS ), що дозволяє дизайнеру виражати взаємозв'язки між ресурсами або керувати REST-клієнтом у робочому процесі операції.

Коротше кажучи, CRUD - це набір примітивних операцій (здебільшого для баз даних та статичних сховищ даних), тоді як REST є стилем API дуже високого рівня (в основному для веб-служб та інших "живих" систем).

Перший маніпулює базовими даними, другий взаємодіє зі складною системою.


3
@Javier Дякуємо за те, що їх розділили. Я використовував REST навчання Rails, і мені склалося враження, що це заміна CRUD (про яку я дізнався з тих пір ... ім'я, тобто я вже використовував його, просто не знав, як його назвати) ... обернулося REST vs CRUD від порівняння 2 яблук до порівняння яблук та апельсинів. Дякую
Джессі Блек

2
@Maudicus: я думаю, що це дуже часто, оскільки RoR включає в себе шар CRUD (як і більшість (кожен?) Фреймворк), і це дозволяє легко (автоматично?) Додавати API REST поверх цього, легко подумати, що це все, що REST. Але тоді ви можете додати функціональність поверх CRUD, але позаду REST API, роблячи їх все більш і більш різними.
Хав'єр

1
Ваша відповідь правильна, але приклад не є оптимальним: коментар може звестись до одного db-рядка, і чи не можливо реалізувати динамічні зміни до пов’язаних об’єктів за допомогою db тригерів? Я відчуваю, що в спокійних api хоч трохи більше, ніж просто грубі операції, і ваша відповідь чітко переносить це відчуття.
didierc

2
Отже ... те саме, інший шар :)
AlikElzin-kilaka

Дуже дякую вам за це! Я додам, що обмеження дієслів HTTP операціями CRUD призводить до впровадження REST буквально як CRUD, з великою кількістю інструментів, що узагальнюють котло CRUD та пропускають місце для цієї спеціальної логіки "роботи на коментарі".
сомпіласар

99

Перш за все, обидва є просто загальними ініціалами; вони нічого не бояться.

Тепер, CRUD - це простий термін, який був скорочений, оскільки це загальна особливість у багатьох програмах, і CRUD простіше сказати . Він описує 4 основні операції, які можна виконувати над даними (або ресурсом). Створення, читання, оновлення, видалення.

REST, однак, це названа практика (як і AJAX), а не сама технологія. Це заохочує використання можливостей, які давно були притаманні протоколу HTTP, але рідко використовуються.

Коли у вас є URL (Уніфікований локатор ресурсів ) і ви вказуєте на нього свого браузера адресною лінією, ви надсилаєте HTTP-запит . Кожен HTTP-запит містить інформацію, яку сервер може використовувати, щоб знати, яку відповідь HTTP повернути тому клієнту, який видав запит.

Кожен запит містить URL-адресу, тому сервер знає, до якого ресурсу ви хочете отримати доступ, але він також може містити метод . Метод описує, що робити з цим ресурсом.

Але ця концепція "методу" використовувалася не дуже часто.

Зазвичай люди просто посилаються на сторінки за допомогою методу GET та видають будь-який тип оновлень (видалення, вставки, оновлення) за допомогою методу POST.

І через це ви не могли розглядати один ресурс (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 ви створюєте розумніші форми, оскільки вони використовують інші методи HTTP, крім POST, і програмуєте ваш сервер, щоб він міг розрізняти методи , а не лише 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 architecture", про які ви можете прочитати у Вікіпедії, інших статтях чи книгах, якщо вам це цікаво. З іншого боку, для самого CRUD не набагато більше.


4
вибачте, але REST це набагато більше , ніж CRUD. здебільшого тому, що ресурси містять набагато більше, ніж один запис кожен, і кожна операція робить набагато більше, ніж оновлення запису.
Хав'єр

11
Гаразд. Я згоден. Чому ви шкодуєте? Я не сказав, що це не набагато більше, ніж CRUD. Я думаю, що саме це я і сказав.
Ям Маркович

4
Це має бути правильна відповідь.
Брендон

Специфікація HTML дозволяє лише методи GET і POST для подання форми, тому інші методи не використовувались у сервісах обробки запитів від веб-клієнтів до набуття широкого поширення AJAX. Деякі сервіси використовують приховане поле введення з назвою "_method" як вирішення для визначення способу, відмінного від POST, при цьому все ще надсилаючи форму за допомогою методу POST.
Кеннет Сундквіст

20

REST означає «передачу репрезентативного стану», що означає, що справа стосується передачі та зміни стану певного ресурсу в системі.

REST дуже задіяний, оскільки теорія, що стоїть за REST, потрапляє у використання засобів масової інформації, гіпермедіа та базового протоколу для управління інформацією у віддаленій системі.

CRUD, з іншого боку, є мнемонічним для загальних операцій, необхідних для даних у базі даних: Створити Отримати оновлення Видалити. Але це насправді не стає глибшим за це.

Тож це відповідь на ваше запитання, але я зазначу поширену помилку, яку я бачу, коли REST та CRUD обговорюються разом. Багато розробників хочуть вказати REST безпосередньо на CRUD, тому що REST через HTTP передбачає GET PUT POST і DELETE, тоді як CRUD забезпечує CREATE RETRIEVE UPDATE DELETE. Цілком природно хотіти відображати дієслова REST безпосередньо на операціях CRUD.

Однак HTTP використовує стиль "створити або оновити", а CRUD розділяє створення та оновлення. Це робить неможливим (!) Зробити чисте, загальне відображення між ними (!)

GET і DELETE - це просто ... GET === RETRIEVE, і DELETE === DELETE.

Але відповідно до специфікації HTTP, PUT насправді створює та оновлює:

  • Використовуйте PUT для створення абсолютно нового об'єкта, коли ви знаєте про нього все, включаючи його ідентифікатор

  • Використовуйте PUT для оновлення об'єкта (як правило, з повним представленням об'єкта)

POST - дієслово "обробляти", і вважається дієсловом "додавання":

  • Використовуйте POST, щоб додати новий об’єкт до колекції - тобто створити новий об’єкт

  • POST також використовується, коли жоден з інших дієслів не підходить, оскільки специфікація HTTP визначає його як дієслово "обробка даних"

  • Якщо ваша команда зависла на POST, пам’ятайте, що вся WWW була побудована на GET і POST;)

Тож, хоча між REST та CRUD існує схожість, я вважаю, що більшість команд робить помилку зробити еквівалент між ними. Команді справді потрібно бути обережними, визначаючи API REST, щоб не надто зависати на мнемонічній CRUD, оскільки REST як практика дійсно має багато додаткових складностей, які не чітко відображають CRUD.


7

CRUD визначає мінімальний набір основних дієслів зберігання даних для читання та запису даних: створювати, читати, оновлювати та видаляти. Потім ви можете будувати інші операції, агрегуючи ці. Зазвичай вони вважаються операціями з базою даних, але те, що вважається БД, є довільним (наприклад, це може бути реляційна СУБД, але також можуть бути файлами YAML).

REST - це "архітектурний стиль", який зазвичай включає операції CRUD та інші операції вищого рівня, які слід виконувати на якійсь концепції "ресурси" (довільно, але це сутності у вашій програмі). REST має купу обмежень, які роблять його цікавим (і особливо добре поєднується з HTTP).

Інтерфейс REST може, але не повинен піддавати всі дії CRUD на певному ресурсі. Доступне для інтерфейсу REST довільне і може змінюватися через системні дозволи, міркування інтерфейсу та те, наскільки це було гарячим у день розробки та створення інтерфейсу. Гарячі дні призводять зазвичай до більш мінімалістичних інтерфейсів, хоча це може бути і навпаки.


Спасибі Яр. Здається, моє "Чи все, що CRUD робить, і більше?" так, технічна здатність REST застосовується до більш ніж просто записів у базі даних.
Джессі Блек

@Maudicus Я оновив відповідь, але щоб бути конкретним: це може, але НЕ МАЄ.
Дан Розенстарк

Я б не сказав, що вони вимагають, щоб ваша заява вважалася заповненою. Деякі програми за своєю природою не потребують вставок, видалень чи оновлень.
Ям Маркович

@Yam Marcovic, гаразд, налагоджено
Dan Rosenstark

6

CRUD

  • CRUD - це чотири основні типи команд SQL: Створення, читання, оновлення та видалення
  • Більшість додатків мають певну функціональність CRUD
  • Програма CRUD - це форма, яка використовує форми для отримання даних у базу даних та з них

ВІДПОВІДНИЙ

  • REST означає "Представницький державний трансфер" (іноді пишеться "Відпочинок")

  • Він покладається на протокол зв'язку без клієнта-сервера, кешований протокол зв'язку - і практично у всіх випадках використовується протокол HTTP

  • REST - це стиль архітектури для проектування мережевих додатків


2

REST - це щось на зразок веб-сторінки для машин, яку вони можуть переглядати, тоді як CRUD - це щось на зразок SOAP, яке сильно поєднується зі своїми клієнтами. Це основні відмінності. Ofc. вони схожі на поверхні, але CRUD описує основні маніпуляції з об'єктом, тоді як REST може описувати інтерфейс будь-якої програми. Ще одна відмінність у тому, що REST може більше використовувати 4 HTTP-методи. Було б дуже довгою відповіддю, якщо я хочу зібрати всі відмінності, якщо ви перевірите питання щодо REST vs SOAP, то ви знайдете більшість із них.

Я думаю, що плутати REST з CRUD - це дуже поширена помилка, і причина полягає в тому, що розробники не мають часу читати про REST глибоко. Вони просто хочуть використовувати технологію - не розуміючи її - на основі обмежених прикладів стилю CRUD, написаних подібними розробниками. Переважна більшість прикладів та навчальних посібників відображають серйозний брак знань. Зображення ресурсів REST для сутностей та методів HTTP для операцій CRUD цих об'єктів та використання REST без гіперпосилань є лише симптомом цього. За допомогою REST ви позначаєте гіперпосилання (включаючи посилання з методами POST / PUT / DELETE / PATCH) на ваші операції, і ви ідентифікуєте операцію на стороні клієнта, перевіряючи (як правило, специфічний API) зв’язок зв'язку. Якщо клієнт REST не знає, що таке зв'язок, і знає лише методи HTTP і, можливо, деякі шаблони URI, то це не REST-клієнт, а CRUD на HTTP-клієнті. Ще одна поширена помилка, що клієнт REST - це програма на одній сторінці JavaScript, що працює в браузері. Звичайно, ви можете реалізовувати такого клієнта, але REST призначався в основному для автоматичних клієнтів (додатки на сервері, написані розробниками, яких ви навіть не знаєте), а не для клієнтів вручну (написані вами програми браузера, керовані користувачем). Маючи лише одного клієнта браузера, це може бути ознакою того, що вам не потрібен REST, і ви просто переробили проект. У цих випадках CRUD API є життєздатним рішенням, і розробники називають ці CRUD API як REST, оскільки вони не знають різниці. Звичайно, ви можете реалізовувати такого клієнта, але REST призначався в основному для автоматичних клієнтів (додатки на сервері, написані розробниками, яких ви навіть не знаєте), а не для клієнтів вручну (написані вами програми браузера, керовані користувачем). Маючи лише одного клієнта браузера, це може бути ознакою того, що вам не потрібен REST, і ви просто переробили проект. У цих випадках CRUD API є життєздатним рішенням, і розробники називають ці CRUD API як REST, оскільки вони не знають різниці. Звичайно, ви можете реалізовувати такого клієнта, але REST призначався в основному для автоматичних клієнтів (додатки на сервері, написані розробниками, яких ви навіть не знаєте), а не для клієнтів вручну (написані вами програми браузера, керовані користувачем). Маючи лише одного клієнта браузера, це може бути ознакою того, що вам не потрібен REST, і ви просто переробили проект. У цих випадках CRUD API є життєздатним рішенням, і розробники називають ці CRUD API як REST, оскільки вони не знають різниці.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.