Идея RE презентационный S Тейт T ransfer не о доступе к данным в наиболее простом способе.
Вы предложили использовать почтовые запросы для доступа к JSON, который является совершенно допустимым способом доступа к данным и манипулирования ими.
REST - это методология значимого доступа к данным. Когда вы видите запрос в REST, он должен немедленно следить за тем, что происходит с данными.
Например:
GET: /cars/make/chevrolet
скорее всего собираюсь вернуть список шеви авто. Хороший API REST может даже включать некоторые параметры вывода в строку запроса, например, ?output=jsonили ?output=htmlкоторые позволят инициатору решать, в каком формате должна быть закодирована информация.
После недолгих размышлений о том , как разумно включить типизации данных в REST API, я пришел к выводу , что лучший способ определить тип данных , явно было бы с помощью уже существующего расширения файла , такие как .js, .json, .htmlили .xml. Отсутствующее расширение файла будет по умолчанию в любом формате по умолчанию (например, JSON); расширение файла, которое не поддерживается, может вернуть 501 Not Implementedкод состояния .
Другой пример:
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
скорее всего, собирается создать новый шевроле малибу в БД со связанными цветами. Я говорю скорее всего, поскольку REST API не должен быть напрямую связан со структурой базы данных. Это просто маскирующий интерфейс, обеспечивающий защиту истинных данных (представьте, что это средства доступа и мутаторы для структуры базы данных).
Теперь нам нужно перейти к вопросу об идемпотентности . Обычно REST реализует CRUD через HTTP. HTTP использует GET, PUT, POSTи DELETEдля запросов.
Очень упрощенная реализация REST может использовать следующее отображение CRUD:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
Существует проблема с этой реализацией: публикация определяется как неидемпотентный метод. Это означает, что последующие вызовы одного и того же метода Post приведут к различным состояниям сервера. Get, Put и Delete, являются идемпотентными; Это означает, что их многократный вызов должен привести к одинаковому состоянию сервера.
Это означает, что запрос, такой как:
Delete: /cars/oldest
на самом деле может быть реализовано как:
Post: /cars/oldest?action=delete
В то время как
Delete: /cars/id/123456
приведет к тому же состоянию сервера, если вы позвоните ему один раз, или если вы позвоните ему 1000 раз.
Лучшим способом обработки удаления oldestпредмета будет запрос:
Get: /cars/oldest
и использовать IDполученные данные для deleteзапроса:
Delete: /cars/id/[oldest id]
Проблема с этим методом была бы, если бы /carsбыл добавлен другой элемент между тем, когда /oldestбыл запрошен и когда deleteбыл выпущен.