Разница между REST и CRUD

Я изучил REST, и это очень похоже на CRUD (из того, что я читал о CRUD).

Я знаю, что они разные, и мне интересно, если думать, что они похожи, значит, я их не понимаю.

Это то, что REST - это «суперсет» CRUD? Все ли CRUD делает и больше?

Удивительно, но я не вижу в других ответах того, что я считаю реальной разницей между REST и CRUD: чем управляет каждый из них.

CRUD означает основные операции, которые необходимо выполнить в хранилище данных. Вы напрямую обрабатываете записи или объекты данных; кроме этих операций, записи являются пассивными объектами. Обычно это просто таблицы базы данных и записи.

REST, с другой стороны, работает с представлениями ресурсов, каждое из которых идентифицируется URL. Обычно это не объекты данных, а сложные абстракции объектов.

Например, ресурс может быть комментарием пользователя. Это означает не только запись в таблице комментариев, но также ее связь с ресурсом пользователя, публикацией, к которой прикреплен комментарий, возможно, другим комментарием, на который он отвечает.

Работа с комментарием не является примитивной операцией с базой данных, у нее могут быть значительные побочные эффекты, такие как запуск оповещения для исходного постера, или пересчет некоторых игровых «точек», или обновление некоторого «потока подписчиков».

Кроме того, представление ресурса включает в себя гипертекст (проверьте принцип HATEOAS ), позволяя разработчику выражать отношения между ресурсами или направляя клиента REST в рабочий процесс операции.

Короче говоря, CRUD - это набор примитивных операций (в основном для баз данных и статических хранилищ данных), в то время как REST - это API-интерфейс очень высокого уровня (в основном для веб-сервисов и других «живых» систем).

Первый манипулирует основными данными, другой взаимодействует со сложной системой.

Во-первых, оба - просто общие инициалы; им нечего бояться.

CRUD - это простой термин, который был сокращен, потому что он является общим свойством во многих приложениях, и проще сказать CRUD . Он описывает 4 основных операции, которые вы можете выполнять с данными (или ресурсами). Создать, прочитать, обновить, удалить.

Однако REST - это именованная практика (как и AJAX), а не сама по себе технология. Он поощряет использование возможностей, которые давно присущи протоколу HTTP, но используются редко.

Если у вас есть URL-адрес (Uniform Resource Locator ) и вы указываете браузер на него адресной строкой, вы отправляете 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 архитектуре» есть много других функций, о которых вы можете прочитать в Википедии, других статьях или книгах, если вам интересно. С другой стороны, самому CRUD не так уж и много.

REST расшифровывается как «передача состояния репрезентации», что означает передачу и изменение состояния некоторого ресурса в системе.

REST становится достаточно сложным, потому что теория REST связана с использованием мультимедиа, гипермедиа и базового протокола для управления информацией в удаленной системе.

CRUD, с другой стороны, является мнемоникой для общих операций, необходимых для данных в базе данных: Create Retrieve Update Delete. Но это действительно не становится глубже, чем это.

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

Однако HTTP использует стиль «создать или обновить», в то время как CRUD разделяет создание и обновление. Это делает невозможным (!) Сделать чистое общее отображение между двумя (!)

ПОЛУЧИТЬ и УДАЛИТЬ легко ... ПОЛУЧИТЬ === ПОЛУЧИТЬ, И УДАЛИТЬ === УДАЛИТЬ.

Но согласно спецификации HTTP, PUT на самом деле представляет собой Create AND Update:

• Используйте PUT, чтобы создать новый объект, когда вы знаете о нем все, включая его идентификатор

• Используйте PUT для обновления объекта (обычно с полным представлением объекта)

POST является глаголом «обработки» и считается глаголом «добавления»:

• Используйте POST, чтобы добавить новый объект в коллекцию, то есть создать новый объект

• POST также используется, когда ни один из других глаголов не подходит, так как спецификация HTTP определяет его как глагол «обработка данных»

• Если ваша команда зацикливается на POST, помните, что вся WWW была построена на GET и POST;)

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

CRUD определяет минимальный набор основных глаголов хранения для чтения и записи данных: создание, чтение, обновление и удаление. Затем вы можете создавать другие операции, объединяя их. Обычно они считаются операциями с базой данных, но то, что считается базой данных, является произвольным (например, это может быть реляционная СУБД, но также могут быть файлы YAML).

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

Интерфейс REST может, но не обязан, отображать все операции CRUD на конкретном ресурсе. То, что доступно в интерфейсе REST, является произвольным и может измениться из-за системных разрешений, соображений пользовательского интерфейса и того, насколько жарко было в день проектирования и создания интерфейса. Обычно жаркие дни приводят к более минималистичным интерфейсам, хотя может быть и обратное.

CRUD

• CRUD - это четыре основных типа команд SQL: создание, чтение, обновление и удаление.
• Большинство приложений имеют некоторые функции CRUD
• Приложение CRUD - это приложение, которое использует формы для получения данных в базу данных и из нее.

ОТДЫХ

• REST расшифровывается как Передача представительского состояния (иногда пишется «ReST»).

• Он опирается на клиент-серверный, кешируемый протокол связи без сохранения состояния - и практически во всех случаях используется протокол HTTP

• REST - это стиль архитектуры для проектирования сетевых приложений

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, потому что они не знают разницы.