REST vs CRUD: Объяснение REST и CRUD операций :перевод

REST vs CRUD: Объяснение REST и CRUD операций :перевод

Некоторая путаница вокруг REST и CRUD связана с перекрытием основных команд, предписанных обоими процессами. Это еще более усиливается сообществом Rails, охватывающим REST и его характер GET, PUT, POST.

Опытные разработчики могут видеть явное сходство между GET, PUT, POST и CREATE, READ, UPDATE, DELETE. Последние команды являются основой CRUD. И хотя сходства нельзя игнорировать, следует отметить, что REST - это не просто точная копия CRUD.

REST: Основы и Принципы

Каждая REST команда сосредоточено вокруг ресурсов. В RESTе, на самом деле ресурс это все на что может указать протокол HTTP. Например, картинка, веб-сайт, документ, или сервис прогноза погоды. Возможности почти безграничны.

Простыми словами, REST расшифровывается как Presentational State Transfer(wiki), архитектурный стиль, разработанный для распределенных гипермедиа, или (Application Programming Interface)интерфейс прикладного программирования. Возможно вы уже слышали другое название API. Другой способ представить API-интерфейс - определить его как веб-сервис, соответствующий архитектурным принципам REST. Каждый API вызывается с помощью стандартного метода HTTP-запроса: POST, GET, PUT и реже DELETE.  DELETE обычно подразумевается, хотя и не обязательно указано.

Термины, определяющие принципы REST, были введены в диссертации доктора Роя Филдинга «Архитектурные стили и проектирование сетевой инфраструктуры программного обеспечения». В целом, REST можно рассматривать как стандарт в разработке сервисных приложений. Он предлагает альтернативу простому объектному протоколу доступа (SOAP), COBRA, RMI и многим другим.

Принципы REST

Существует 6 обязательных ограничений у RESTа. Вот они:

Модель Client-Server

Эту модель подчеркивает тот факт, что REST является распределенным подходом через характерное разделения архитектуры между клиентом и сервером. Каждый сервис имеет несколько возможностей и прослушивает запросы. Запросы совершаются клиентом и принимаются или отклоняются сервером.

Отсутствие состояния

Из-за характера отсутствия состояния этот принцип является руководящим в архитектуре RESTful. Он определяет, какие команды могут быть предоставлены между клиентом и сервером. Реализация запросов без сохранения состояния означает, что связь между потребителем и сервисом инициирована запросом, и запрос содержит всю необходимую информацию для ответа сервера.

Кэширование

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

Единообразие интерфейса/контракта

RESTful архитектура следует принципам, которые определяют Единый Контракт. Они запрещают использование нескольких отдельных интерфейсов в API. Вместо этого, один интерфейс распределяется по гипермедиа-соединениями.

К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия:

  • Идентификация ресурсов

Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.

  • Манипуляция ресурсами через представление

Если клиент хранит представление ресурса, включая метаданные — он обладает достаточной информацией для модификации или удаления ресурса.

  • «Самоописываемые» сообщения

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

  • Гипермедиа как средство изменения состояния приложения (HATEOAS)

Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить, что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, RFC 5988 и JSON Hypermedia API Language являются двумя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах.*

Слои

Этот принцип делает архитектуру RESTful - масштабируемой. В многоуровневой системе несколько слоев используются для увеличения и расширения интерфейса. Ни один из слоев не может видеть другой.

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

Код по требованию (необязательное ограничение)

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

REST: в двух словах

REST соответсвует набору определяющих принципов для разработки API. Он использует HTTP-протоколы, такие как GET, PUT, POST, чтобы связать ресурсы с действиями в отношениях клиент-сервер. В дополнение к модели клиент-сервер у него есть несколько других определяющих ограничений. Принципы RESTful архитектуры служат, чтобы создать стабильное и жизнеспособное приложение, которое предлагает простоту и удовлетворение конечному пользователю.

CRUD: Основы и Принципы

С лучшим пониманием RESTful архитектуры, время погрузиться в CRUD.

CRUD это акроним от CREATE, READ, UPDATE, DELETE. Это форма стандартных команд баз данных, которые основывают CRUD.

Многие разработчики в лучшем случае, видят эти команды как примитивное руководство(*отклонюсь от перевода и добавлю свои 3 копейки, по сути это самый минимум тех знаний которые от вас как от программиста могут потребовать начиная с позиции Junior разработчика*)

Это потому, что CRUD не был разработан как способ разработки современного API. Фактически, CRUD берет свое начало в записях баз данных.

По определению, CRUD это больше цикл чем архитектурный подход. На любом динамическом вебсайте, существует многообразие CRUD приемов.

Для примера, покупатель на eCommerce сайте может CREATE(создать) учетную запись, UPDATE(обновить) информацию по учетной записи, и DELETE(удалить) товары из корзины.

Менеджер операционного склада использует этот же сайт, чтобы CREATE(создать) запись о транспортировке товаров, RETRIEVE(получить) их как понадобится, и UPDATE(обновить) список сырья. Retrieve иногда заменяет READ(чтение) в цикле CRUD.

Происхождение Баз Данных

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

В современной разработке программного обеспечения CRUD превзошел свое происхождение как основополагающие функции базы данных и теперь сопоставляет себя с принципами разработки для динамических приложений, таких как протокол HTTP, DDS и SQL.

Принципы CRUD

Как уже говорилось выше, принципы CRUD операций определены как CREATE(создание), READ/RETRIEVE(чтение/получение), UPDATE(обновление), и DELETE(удаление).

Создать

CREATE procedures generate new records via INSERT statements.

Прочитать/Получить

READ процедуры читают данные основываясь на входных параметрах. Подобным образом, RETRIEVE процедуры берут данные основываясь на входных параметрах.

Обновить

UPDATE процедуры изменяют записи без их затирания.

Удалить

DELETE процедуры удаляют записи, где задано.

REST и CRUD общие черты

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

Отсутствие ясности между ними теряется для многих, когда они не могут определить, когда заканчивается CRUD и начинается REST. Мы упомянали ранее, что CRUD может быть сопоставлен к DDS, SQL, и HTTP протоколами. И что HTTP протоколы транспорт между ресурсами в RESTful архитектуре, часть ядра REST основы.

Отображение принципов CRUD в REST означает понимание того, что GET, PUT, POST и CREATE, READ, UPDATE, DELETE имеют поразительное сходство, поскольку первая группа применяет принципы последней.

Однако важно также отметить, что часть архитектуры программного обеспечения RESTful означает больше, чем отображение команд GET, PUT, POST.

REST и CRUD: Какие отличия?

CRUD это операции которые могут сопоставляться с REST, по дизайну. Permanence, as defined in the context of CRUD, is a smart way for applications to mitigate operational commands between clients and services.

But REST governs much more than permanence within its principles of architecture. Here are some of the ways that REST is not only different than CRUD but also offers much more:

  • REST is an architectural system centered around resources and hypermedia, via HTTP protocols
  • CRUD is a cycle meant for maintaining permanent records in a database setting
  • CRUD principles are mapped to REST commands to comply with the goals of RESTful architecture

В REST-е:

  • Представление должно быть единым относительно ресурсов
  • Гипермедиа представляет отношения между ресурсами
  • Только одно вхождение в API создает один интерфейс, тогда гиперссылка создает отношения

Путь вперед

Разработчики выбирают REST по ряду причин:

  1. Производительность
  2. Масштабируемость
  3. Простота
  4. Изменчивость
  5. Видимость
  6. Портативность
  7. Жизнеспособность

Не удивительно, запрос на RESTful архитектуру продолжает расти из года в год. И так как REST становится еще более популярен как архитектурный стиль, программистам нужно уметь отличать различия между принципами других инструментов как SOAP, COBRA, и RMI.

Перевод на основе статьи:
https://www.bmc.com/blogs/rest-vs-crud-whats-the-difference/