REST API-зачем использовать PUT DELETE POST GET?


Итак,я просматривал некоторые статьи о создании REST API. И некоторые из них предлагают использовать все типы HTTP-запросов: like PUTDELETEPOSTGET. Мы бы создали например .php и написать API таким образом:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

хорошо, конечно-я не знаю много о веб-службах (пока). Но, не было бы проще просто принять JSON объект через обычный POST или GET (которая будет содержать имя метода и все параметры), а затем ответить в JSON, а также. Мы можем легко сериализовать / десериализовать через PHP json_encode() и json_decode() и делать все, что мы хотим с этими данными без необходимости иметь дело с различными методами HTTP-запроса.

Я что-то пропустила?

обновление 1:

ОК-после копания через различные API и узнать много нового о XML-RPC,JSON-RPC,мыло,остальное Я пришел к вывод, что этот тип API является здравым. На самом деле stack exchange в значительной степени использует этот подход на своих сайтах, и я думаю, что эти люди знают, что они делают Stack Exchange API.

8   143   2011-01-01 08:57:06

8 ответов:

идея REпредставления SТэйт Transfer не о доступе к данным самым простым способом.

вы предложили использовать запросы post для доступа к JSON, что является совершенно допустимым способом доступа к данным/манипулирования ими.

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

например:

GET: /cars/make/chevrolet

вероятно, собирается вернуть список автомобилей chevy. хороший REST api может даже включать некоторые параметры вывода в строку запроса, например ?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] }

скорее всего, будет создан новый chevy malibu в БД с соответствующими цветами. Я говорю скорее как REST api не делает необходимо иметь непосредственное отношение к структуре базы данных. Это просто маскирующий интерфейс, так что истинные данные защищены (подумайте об этом, как аксессоры и мутаторы для структуры базы данных).

теперь нам нужно перейти к вопросу idempotence. Как правило, остальные реализует CRUD через HTTP. HTTP использует GET,PUT,POST и DELETE для запросов.

очень упрощенная реализация REST может использовать следующее отображение CRUD:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

существует проблема с этой реализацией: Post определяется как неидемпотентный метод. Это означает, что последующие вызовы одного и того же метода 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 элемент был добавлен между when /oldest был запрошен и когда delete был выдан.

Это вопрос безопасности и ремонтопригодности.

безопасные методы

по возможности, вы должны использовать "безопасные" (однонаправленные) методы, такие как GET и HEAD, чтобы ограничить потенциальную уязвимость.

идемпотентные методы

когда это возможно, вы должны использовать "идемпотентные" методы, такие как GET, HEAD, PUT и DELETE, которые не могут иметь побочных эффектов и поэтому менее подвержены ошибкам / легче управление.

источник

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

Вы спрашивали:

не было бы проще просто принять объект JSON через обычный $_POST, а затем ответить в JSON, а также

из Википедии на остальное:

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

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

пользовательские протоколы данных (даже если они построены поверх стандартных, таких как SOAP или JSON) не поощряются и должны быть сведены к минимуму, чтобы наилучшим образом соответствовать идеологии REST.

SOAP RPC через HTTP, с другой стороны, рекомендует каждому конструктору приложений определить новый и произвольный словарь существительных и глаголов (например getUsers(), savePurchaseOrder(...)), обычно накладывается на глагол HTTP 'POST'. Это игнорирует многие из существующих возможностей HTTP, таких как аутентификация, кэширование и согласование типов контента, и может оставить конструктор приложений повторно изобретать многие из этих функций в новом словаре.

реальные объекты могут быть в любом формате. Идея состоит в том, чтобы повторно использовать как можно больше HTTP, чтобы предоставить ваши операции, которые пользователь хочет выполнить на этом ресурсе (запросы, управление состоянием/мутация, удаление).

Вы спрашивали:

Я что-то пропустила?

существует гораздо больше, чтобы знать о REST и синтаксис URI/HTTP глаголы сами. Например, некоторые глаголы являются идемпотентными, другие нет. Я не вижу ничего об этом в вашем вопросе, поэтому я не потрудитесь нырнуть в него. Другие ответы и Википедия имеют много хорошей информации.

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

в отношении использования расширения для определения типа данных. Я заметил, что MailChimp API делает это, но я не думаю, что это хорошая идея.

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

мой звук, как хорошая идея, но я думаю, что" старый " подход лучше-с помощью HTTP-заголовков

GET /xxx/cars/1
Accept: application/json

также заголовки HTTP намного лучше для перекрестной передачи данных типа (если когда-нибудь кому-то это понадобится)

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  

Я что-то пропустила?

да. ; -)

Это явление существует из-за единый интерфейс ограничение. Отдых любит использовать уже существующие стандарты вместо того, чтобы изобретать велосипед. Стандарт HTTP уже доказал свою высокую масштабируемость (веб работает некоторое время). Почему мы должны чинить то, что не сломано?!

Примечание: равномерное ограничение интерфейса важно, если вы хотите отделите клиентов от службы. Это похоже на определение интерфейсов для классов, чтобы отделить их друг от друга. Конвертер ofc. здесь единый интерфейс состоит из стандартов типа HTTP,типы MIME, URI,RDF, связанные данные vocabs,hydra vocab и т. д...

хорошая семантика важна в программировании.

использование большего количества методов, кроме GET / POST, будет полезно, потому что это увеличит читаемость вашего кода и упростит его обслуживание.

Почему?

потому что вы знаете, что GET будет получать данные из вашего api. Вы знаете, что POST добавит новые данные в вашу систему. Сказал, что будет делать обновления. Удалить удалит строки и т. д., и т. д.,

Я обычно структурирую свои веб-службы RESTFUL так, чтобы у меня функция обратного вызова называется то же самое, что и метод.

Я использую PHP, поэтому я использую function_exists (я думаю, что его называют). Если функция не существует, я бросаю 405 (метод не разрешен).

Билл Веннерс: в своем блоге под названием "Почему REST не удалось" вы сказали, что нам нужны все четыре http-глагола - GET, POST, PUT и DELETE-и сокрушались, что поставщики браузеров только получают и публикуют.- Зачем нам все четыре глагола? Почему недостаточно получить и опубликовать?

Эллиот Расти Гарольд: в HTTP есть четыре основных метода: GET, POST, PUT и DELETE. GET используется большую часть времени. Он используется для всего, что безопасно, что не вызывает никаких побочных эффектов. GET может быть заложен, кэширован, связан, передан через прокси-сервер. Это очень мощная операция, очень полезная операция.

сообщение, напротив, пожалуй, самая мощная операция. Он может делать все что угодно. Нет никаких ограничений относительно того, что может произойти, и в результате вы должны быть очень осторожны с этим. Вы не закладываете его. Вы не кэшируете его. Вы не можете предварительно принести его. Вы ничего не делаете с сообщением, не спрашивая пользователя. Ты хочешь это сделать? Если пользователь нажимает кнопка, вы можете разместить некоторый контент. Но вы не будете смотреть на все кнопки на странице, а начнете беспорядочно нажимать их. В отличие от этого браузеры могут просматривать все ссылки на странице и предварительно извлекать их или предварительно извлекать те, которые, по их мнению, с наибольшей вероятностью будут следовать дальше. И на самом деле некоторые браузеры и расширения Firefox и различные другие инструменты пытались сделать это в тот или иной момент.

PUT и DELETE находятся посередине между GET и POST. Разница между PUT или DELETE и POST - это то, что PUT и DELETE являются *идемпотентными, тогда как POST-нет. Положить и удалить можно повторить при необходимости. Допустим, вы пытаетесь загрузить новую страницу на сайте. Скажем, вы хотите создать новую страницу в http://www.example.com/foo.html, поэтому вы вводите свой контент и помещаете его на этот URL. Сервер создает эту страницу по указанному URL-адресу. Теперь предположим, что по какой-то причине ваше сетевое соединение отключается. Вы не уверены, что запрос прошел или нет? Может быть, сеть работает медленно. Возможно, была проблема с прокси-сервером. Так что это совершенно нормально, чтобы попробовать его снова, или снова-столько раз, сколько вам нравится. Потому что поместить один и тот же документ в один и тот же URL-адрес десять раз не будет отличаться от его однократного размещения. То же самое верно и для удаления. Вы можете удалить что-то десять раз, и это то же самое, что удалить его один раз.

напротив, сообщение, может вызвать что-то другое, чтобы произойти каждый раз. Представьте, что вы проверяете из интернет-магазина по нажатие кнопки Купить. Если вы отправите этот запрос снова, вы можете в конечном итоге купить все в своей корзине во второй раз. Если вы отправите его снова, вы купили его в третий раз. Вот почему браузеры должны быть очень осторожны при повторении операций POST без явного согласия пользователя, потому что POST может вызвать две вещи, если вы сделаете это дважды, три вещи, если вы сделаете это три раза. С PUT и DELETE существует большая разница между нулевыми запросами и одним, но нет никакой разницы между ними одна просьба и десять.

пожалуйста, посетите url для получения более подробной информации.http://www.artima.com/lejava/articles/why_put_and_delete.html

обновление:

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

рассмотрим следующий пример:

a = 4;

a++;

первый пример является идемпотентным: независимо от того, сколько раз мы выполняем это утверждение, a всегда будет 4. Второй пример не является идемпотентным. Выполнение этого 10 раз приведет в другом результате, как при запуске 5 раз. Поскольку оба примера изменяют значение a, оба являются небезопасными методами.