Содержание

Что такое REST, RESTFul и CRUD

REST — это концепция для взаимодействия компонентов основанный на протоколе HTTP. Не хочу останавливаться на скучной теории (вики в помощь), а дам простое объяснение применительно к сайтам.

В Сети обмен происходит по протоколу HTTP: запрос — ответ. Для того, чтобы передать какие-то данные, их нужно как-то идентифицировать, то есть указать их «признак», «действие» или что-то подобное. И поэтому раньше данные требовалось оформить в виде какого-то сложного формата, обычно это XML или Json.

Так вот, REST говорит что этого делать не нужно. Данные передаём как есть, только у HTTP-запроса указывается метод (параметр) для этих данных. Обычно мы оперируем GET и POST, поскольку они работают «из коробки» в HTML и их поддерживает любой браузер. Но на самом деле, метод у HTTP может быть абсолютно любым. Есть некие общепринятые: PUT, DELETE, OPTIONS, PATCH, но это совсем не стандарт.

То есть, например мы хотим отправить на сервер GET-запрос по адресу

сайт/task и получить список задач (таски). Потом мы хотим добавить новую задачу: отправляем на тот же адрес сайт/task, но уже методом POST. Потом решили, что для редактирования задачи нужно отправить уже PUT и опять же на тот же адрес. И, уж коли пошла такая пьянка, то отправляем и метод DELETE для удаления какой-то задачи.

Формирование GET-запроса очень простое — достаточно набрать адрес в браузере. Для POST уже нужна html-форма с method=post. Эти же методы прекрасно работают и через AJAX. Но, что касается PUT и DELETE, то ни HTML, ни браузер о них ничего не знают. Формально мы всё-таки можем их указывать, но наткнёмся на последнюю стенку — сервер, который также как правило ничего не знает об этих методах и рубанётся с ошибкой 501 или 405.

Таким образом, хоть HTTP и поддерживает произвольные методы, но в реальности работают только два: GET и POST.

Чтобы обойти это ограничение и применить REST к нашим сайтам, придумали хитрость. Все «нестандартные» запросы в своём теле должны содержать отдельное поле, где и указывается «желаемый» метод.

Устоявшаяся практика — метод указывать в поле _method формы или Ajax-запроса.

<form method="POST">
	<input type="hidden" name="_method" value="PUT">
	... прочие данные формы ...
</form>

То есть реальная отправка это POST, но приложение проверяет поле _method и по нему уже принимает решение что делать дальше.

Такой разбор выполняет роутер приложения. Если это так, то правила роутинга указываются примерно так:

[
    'method' => 'POST', // create new task (Create)
    'pattern' => 'task',
    'action' => '\Controller\Task\Task@create',
],
[
    'method' => 'GET', // task show (Read)
    'pattern' => 'task',
    'action' => '\Controller\Task\Task@read',
],
[
    'method' => 'PUT', // update/edit task (Update)
    'pattern' => 'task',
    'action' => '\Controller\Task\Task@update',
],
[
    'method' => 'DELETE', // delete task (Delete)
    'pattern' => 'task',
    'action' => '\Controller\Task\Task@delete',
]

Обратите внимание, что во всех случаях используется один http-адрес: сайт/task — меняются только методы, которые указываются либо в html-форме, либо Ajax-запросе.

Здесь мы подходим к другой концепции — CRUD, которая не что иное, как аббревиатура от Create, Read, Update, Delete — Создать, Прочитать, Обновить, Удалить. Это не что иное, как основные операции для подавляющего большинства данных.

CRUD нужен для того, чтобы разделить программный код на отдельные части, каждая из которых отвечает за свои действия. В данном примере будет использован php-класс \Controller\Task\Task, где каждый http-метод будет выполнен своим php-методом:

  • для POST будет выполнен метод create()
  • для GET будет выполнен метод read()
  • для PUT будет выполнен метод update()
  • для DELETE будет выполнен метод delete()

Если не использовать REST, то скорее всего пришлось бы указывать действие либо по отдельному url-адресу, либо в get-параметрах. Как-то так:

  • сайт/task/create
  • сайт/task/update/7
  • сайт/task/delete/5
  • сайт/task?action=create
  • сайт/task?action=update&id=7
  • сайт/task?action=delete&id=5

Для REST, конечно, требуется хоть какой-то роутинг, способный понимать _method. В общем случае это будет так:

$method = 'get'; // метод по умолчанию
 
if ($_POST) {
    if (isset($_POST['_method'])) 
        $method = $_POST['_method'];
    else 
        $method = 'post';
}
...

Дальше роутер смотрит правила и находит php-метод для запуска.

REST — это только концепция, набор правил. Если же применять эти правила к приложению, то уже говорят о

RESTFul. Например REST предполагает использование модели «клиент-сервер». Если мы предположим, что сервер — это реальный сервер хостинга, а клиент — пользователь сайта, то для RESTFul нужно уже настраивать реальный сервер, чтобы он понимал используемые http-методы. Вряд ли кто-то будет это делать, поэтому с этой точки зрения приложение не может считаться RESTFul.

Но, с другой стороны, если REST-сервер — это просто абстракция, то какая нам разница как вообще работает реальный сервер, если его основная задача — просто отдавать и принимать что нам нужно? Даже если мы используем хитрость с _method, это работает как положено, а значит приложение соответствует RESTFul.

В целом стоит отметить, что сейчас REST и RESTFul — фактически синонимы. Если php-приложение может принимать хоть каким-то способом http-метод, то считается, что это уже полноценный RESTFul. Нужно просто понимать, что архитектура REST позволяет нам использовать HTTP примерно так, как он изначально и задумывался.

Создание сайтов (Украина) →

Как работать с php-сессиями и что такое flash-сессии

Как изменить стартовую страницу в Slimjet (Chrome)

🌐 Что такое API и CRUD простыми словами

Что такое API

API (Application Programming Interface) – это программный интерфейс. Он обеспечивает взаимодействие двух программ между собой и позволяет без особых усилий встраивать контент с любого сайта. Основной задачей API является создание связи между двумя приложениями. API позволяет отправлять запросы на передачу или получение информации. Взаимодействие осуществляется через JSON, а данные получаем в приложениях с помощью API-запросов. API-запрос включает в себя 4 компонента: endpoint (точка приема запроса), header (заголовок), method (метод) и data (данные). После вызова всех компонентов мы можем построить API-запрос.

CRUD-операции

CRUD-операции включают в себя 4 функции: Create (создание), Read (чтение), Update (редактирование) и Delete (удаление). Это основные методы работы с базами данных. Операции CRUD предназначены для редактирования данных программы. Давайте рассмотрим подробнее, что означает каждая операция:

  • GET – метод GET позволяет получить информацию из источника/базы данных.
  • POST – метод POST позволяет вносить информацию в источник/базу данных.
  • PUT – метод PUT позволяет обновлять существующую информацию в источнике/базе данных.
  • DELETE – метод DELETE удалять существующую информацию из источника/базы данных.

JSON

JSON (JavaScript Object Notation) используется для представления данных на сервере в текстовом формате. Он легко читается как людьми, так и машинами. Вот как выглядят данные в JSON:

Типы API

  • Open API – означает, что API находится в свободном доступе и открыт для всех.
  • Partner API – в данном случае происходит взаимодействие между сервером и клиентами.
  • Private API – защищенный API, может использоваться только для внутренних операций, например, платежей.

API – это мощный инструмент для взаимодействия приложений на стороне клиента и сервера. API обеспечивает защищенность, скорость и масштабируемость для приложений eCommerce. Он помогает разработчикам отправлять данные клиентам и в наши дни используется повсеместно.

***

Использование API — один из тех «магических» навыков, которые открывают мир новых возможностей, а Python — отличный инструмент, чтобы таким навыком овладеть.

Чтобы не разочаровываться в ужасном API и не играть в угадайку на каждом шагу, стоит использовать лучшие известные практики. Рассмотрим их в небольшом обзоре.

Технологии прогрессируют быстро и даже для лучших из них появляются альтернативы. Разбираем преимущества и недостатки REST и GraphQL, чтобы выбрать лучший вариант.

Источники

  • https://dev.to/iftakher_hossen/learn-about-api-1cae

Тонкости управления пользователями и доступом в облачном окружении

31 октября Онлайн Бесплатно

Лидеры цифровой трансформации

18 ноября Онлайн Бесплатно

Koshelek delivery meetup

10 ноября Онлайн Бесплатно

Ведущий JAVA разработчик

Москва, от 250000 RUB до 350000 RUB

QA Engineer

Москва, от 3000 USD

Junior DBA

Москва, по итогам собеседования

+ Показать еще Опубликовать вакансию

Компьютерные сети от А до Я: классификация, стандарты и уровни

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

Разбираем по косточкам компьютерные сети: HTTP, TCP, REST

Большинство разговоров о компьютерных сетях сводится к набору аббревиатур: HTTP, TCP, REST. Разберёмся в том, как всё устроено.

8 книг по компьютерным сетям

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

Что такое CRUD? | Codecademy

Создание, чтение, обновление, удаление

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

Парадигма CRUD распространена при создании веб-приложений, поскольку она обеспечивает запоминающуюся основу для напоминания разработчикам о том, как создавать полные, пригодные для использования модели. Например, давайте представим систему для отслеживания библиотечных книг. Мы можем представить себе, что в этой гипотетической библиотечной базе данных будет книг ресурсов, в которых будет храниться книг объектов. Допустим, объект book выглядит так:

 «книга»: {
  "id": <Целое>,
  «заголовок»: ,
  «автор»: ,
  «isbn»: <Целое>
}

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

Создать — это будет состоять из функции, которую мы будем вызывать при добавлении новой библиотечной книги в каталог. . Программа, вызывающая функцию, предоставит значения для «название» , «автор» и «ISBN» . После вызова этой функции в ресурсе books должна появиться новая запись, соответствующая этой новой книге. Кроме того, новой записи присваивается уникальный id , который можно использовать для доступа к этому ресурсу позже.

Чтение — будет состоять из функции, которая будет вызываться для просмотра всех книг, находящихся в настоящее время в каталоге. Этот вызов функции не изменит книги в каталоге — он просто извлечет ресурс и отобразит результаты. У нас также была бы функция для получения одной книги, для которой мы могли бы указать название, автора или ISBN. Опять же, эта книга не будет изменена, только восстановлена.

Обновление — Должна быть функция для вызова, когда информация о книге должна быть изменена. Программа, вызывающая функцию, предоставит новые значения для «название» , «автор» и «ISBN» . После вызова функции соответствующая запись в ресурсе books будет содержать новые предоставленные поля.

Удалить — Должна быть функция для удаления библиотечной книги из каталога. Программа, вызывающая функцию, должна предоставить одно или несколько значений ( «название» , «автор» и/или «isbn» ) для идентификации книги, а затем эта книга будет удалена из списка 9.0007 книг ресурсов. После вызова этой функции ресурс books должен содержать все книги, которые у него были до этого, за исключением только что удаленной.

CRUD и REST

В среде REST CRUD часто соответствует методам HTTP POST, GET, PUT и DELETE соответственно. Это основные элементы системы постоянного хранения.

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

Представьте, что мы работаем с системой, которая отслеживает блюда и соответствующие цены для ресторана. Давайте посмотрим, как мы будем реализовывать операции CRUD.

Создать

Для создания ресурсов в среде REST мы чаще всего используем метод HTTP POST. POST создает новый ресурс указанного типа ресурса.

Например, давайте представим, что мы добавляем новый продукт в сохраненный список блюд для этого ресторана, и блюдо объектов хранятся в ресурсе тарелок . Если бы мы хотели создать новый элемент, мы бы использовали запрос POST:

Request:

 POST http://www.myrestaurant.com/dishes/

Body —

 {
  "блюдо": {
    "name": "Тост с авокадо",
    "цена": 8
  }
}

Это создает новый элемент с именем значением «Тост с авокадо» и ценой значением 8. После успешного создания сервер должен вернуть заголовок со ссылкой на вновь созданный ресурс, вместе с кодом ответа HTTP 201 (СОЗДАНО).

Ответ:

Код состояния — 201 (СОЗДАНО)

Тело —

 {
  "блюдо": {
    "идентификатор": 1223,
    "name": "Тост с авокадо",
    "цена": 8
  }
}

Из этого ответа мы видим, что блюдо с именем «Тост с авокадо» и ценой 8 было успешно создано и добавлено к ресурсу блюд .

Чтение

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

GET можно использовать для чтения всего списка элементов:

Запрос:

 GET http://www.myrestaurant.com/dishes/

Ответ: Код состояния — 200 (ОК)

Тело —

 {
  "блюда": [
    {
      "идентификатор": 1,
      "name": "Роллы с начинкой",
      "цена": 6
    },
    {
      "идентификатор": 2,
      "name": "Палочки с моцареллой",
      "цена": 7
    },
    ...
    {
      "идентификатор": 1223,
      "name": "Тост с авокадо",
      "цена": 8
    },
    {
      "идентификатор": 1224,
      "name": "Мюсли и Йогурт",
      "цена": 5
    }
  ]
}

Запросы GET также можно использовать для чтения определенного элемента, если в запросе указан его id :

Запрос:

 GET http://www. myrestaurant.com/dishes/1223

Код состояния — 200 (ОК)

Тело —

 {
  "идентификатор": 1223,
  "name": "Тост с авокадо",
  "цена": 8
}

После этого запроса информация в базе данных не изменилась. Элемент с идентификатором id 1223 был получен из ресурса блюд и не изменен. Если ошибок нет, GET вернет HTML или JSON нужного ресурса вместе с кодом ответа 200 (ОК). В случае ошибки чаще всего возвращается код ответа 404 (НЕ НАЙДЕНО).

Обновление

PUT — это метод HTTP, используемый для операции CRUD, Обновление.

Например, если цена на тосты с авокадо выросла, мы должны войти в базу данных и обновить эту информацию. Мы можем сделать это с помощью запроса PUT.

Запрос:

 ПОЛУЧИТЬ http://www.myrestaurant.com/dishes/1223

Кузов —

 {
  "блюдо": {
    "name": "Тост с авокадо",
    "цена": 10
  }
}

Этот запрос должен изменить элемент с id 1223, чтобы атрибуты были предоставлены в теле запроса. это блюдо с id 1223 теперь должно по-прежнему иметь имя «Тост с авокадо», но значение цена теперь должно быть 10, тогда как раньше оно было 8.

Ответ: Код состояния — 200 (ОК)

Тело —

 {
  "блюдо": {
    "name": "Тост с авокадо",
    "цена": 10
  }
}

Ответ включает код состояния 200 (ОК), означающий, что операция выполнена успешно. При желании ответ может использовать код состояния 204 (БЕЗ СОДЕРЖИМОГО) и не включать тело ответа. Это решение зависит от контекста.

Удалить

Операция CRUD Удалить соответствует HTTP-методу DELETE. Используется для удаления ресурса из системы.

Допустим, дефицит авокадо в мире достиг критической точки, и мы уже совсем не можем себе позволить подавать это современное лакомство. Мы должны войти в базу данных и удалить элемент, который соответствует «Тост с авокадо», который, как мы знаем, имеет идентификатор из 1223.

Запрос:

 УДАЛИТЬ http://www. myrestaurant.com/dishes/1223

Такой вызов в случае успеха возвращает код ответа 204 (БЕЗ СОДЕРЖИМОГО) без тела ответа. Ресурс блюд больше не должен содержать объект блюд с идентификатором 1223.

Ответ: Код состояния — 204 (БЕЗ СОДЕРЖИМОГО)

Тело — Нет

Вызов GET для ресурса блюд после этого вызова DELETE вернет исходный список блюд с {"id": 1223, "name": "Авокадо". Toast», «price»: 10} запись удалена. Все остальные блюдо объекты в ресурсе блюда должны остаться без изменений. Если бы мы попытались вызвать GET для элемента с id 1223, который мы только что удалили, мы бы получили код ответа 404 (NOT FOUND), а состояние системы должно остаться неизменным.

Вызов DELETE для несуществующего ресурса не должен изменять состояние системы. Вызов должен возвращать код ответа 404 (НЕ НАЙДЕН) и ничего не делать.

Практика CRUD

Функции создания, чтения, обновления и удаления ресурсов являются фундаментальными компонентами используемой модели хранения. Теперь вы видели пару примеров того, как парадигма CRUD может помочь нам в разработке систем. Теперь попробуйте использовать CRUD для составления списка маршрутов для новой примерной модели. Представьте, что мы пытаемся разработать систему, которая отслеживает занятия по тренировкам, включая название каждого занятия, кто его ведет и продолжительность занятия. Пример объект класса будет выглядеть так:

 {
  "учебный класс": {
    "идентификатор": 1
    "name": "Чистая сила",
    «тренер»: «Бицепс Боб»,
    "длительность": 1,5
   }
}

Все классы хранятся в ресурсе классов по адресу www.musclecademy.com/classes .

Для каждой операции CRUD запишите ответы на следующие вопросы:

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

Практические ответы CRUD

1) Создать

Маршрут : POST /classes

Влияние на базу данных : Добавляет класс, указанный в теле запроса, в базу данных : Недавно созданный класс }

Код ответа на успех : 201

2) Читать (все классы)

Маршрут : GET /классы

Эффект на базу данных : нет

. Из всех сохраненных класса]}

Код ответа на успех : 200

3) Читать (один класс)

. Тело : { «класс»: класс с указанным идентификатором }

Код успешного ответа : 200

4) Обновление

Маршрут : PUT /classes/:id

4 Влияние на базу данных 2 5 5 9004 Обновляет класс с указанным идентификатором, чтобы информация о классе была предоставлена ​​в теле запроса

Тело ответа : { "класс": обновленный класс теперь сохранен в базе данных }

Код успешного ответа : 200

5) Удалить

Маршрут : удаление /классы /: ID

Эффект на базу данных : Удаление класса с указанным идентификатором из базы данных

. : 204

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

Узнайте больше на Codecademy

Только Pro

путь навыков

Создать заднее приложение с JavaScript

Floodry,

29 Уроки

PRO только

КУРС

SPRING

SCRUD

0

.STRONS LESTONS 9000.SRALSINGSINGSINGSINGSINGSINGSION и RESTONS .STONS LEDONS 9000.SRESTONS 9000.slisons 9000.slisons 9000. Операции — BMC Software

Некоторая путаница вокруг REST и CRUD связана с перекрытием основных команд, выполняемых обоими процессами. Это еще больше усиливается тем, что сообщество Rails использует REST и его ПОЛУЧИТЬ, ПОЛУЧИТЬ, ПОСТ натур.

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

REST: основа и принципы

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

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

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

  • Простой протокол доступа к объектам (SOAP)
  • Общая архитектура брокера запросов к объектам (CORBA)
  • RMI
  • Многие другие

Принципы REST

Существует шесть основных ограничений REST:

  • Мандаты клиент-сервер
  • Безгражданство
  • Кэш
  • Интерфейс/унифицированный контракт
  • Многоуровневая система
  • Код по запросу 904 (необязательно) 9023 9023.

    Мандат клиент-сервер

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

    Безгражданство

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

    Кэш

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

    Интерфейс/унифицированный контракт

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

    Многоуровневая система

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

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

    Дополнительно: Code-on-Demand

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

    Кратко о REST

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

    CRUD: основа и принципы

    Лучшее понимание архитектуры RESTful пришло время погрузиться в CRUD. CRUD — это аббревиатура от:

    • CREATE
    • READ
    • UPDATE
    • DELETE

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

    По определению, CRUD — это больше цикл, чем архитектурная система. На любом динамическом веб-сайте, вероятно, существует несколько циклов CRUD. Например, покупатель на сайте электронной коммерции может СОЗДАТЬ учетную запись, ОБНОВИТЬ информацию об учетной записи и УДАЛИТЬ товары из корзины.

    Менеджер складских операций, использующий тот же сайт, может СОЗДАВАТЬ записи об отгрузке, ПОЛУЧАТЬ их по мере необходимости и ОБНОВЛЯТЬ списки поставок. Retrieve иногда заменяет READ в цикле CRUD.

    Источники базы данных

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

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

    Принципы CRUD

    Как упоминалось выше, принципы цикла CRUD определяются как CREATE, READ/RETRIEVE, UPDATE и DELETE:

    • CREATE Процедуры генерируют новые записи с помощью операторов INSERT.
    • READ Процедуры считывают данные на основе входных параметров. Точно так же RETRIEVE Процедуры захватывают записи на основе входных параметров.
    • Процедуры UPDATE изменяют записи, не перезаписывая их.
    • УДАЛИТЬ процедуры удалить, где указано.

    Сходства между 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. Постоянство, как определено в контексте CRUD, — это разумный способ для приложений смягчить рабочие команды между клиентами и службами.

    No related posts.