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




работа простыми (8)

Итак, я просматривал некоторые статьи о создании REST API. Некоторые из них предлагают использовать все типы HTTP-запросов: например, PUT DELETE POST GET . Мы будем создавать, например, index.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. Мы можем легко сериализовать / десериализовать через json_encode() и json_decode() PHP и делать все, что захотим, с json_decode() данными, не имея дело с различными методами HTTP-запросов.

Я что-то упускаю?

ОБНОВЛЕНИЕ 1:

Хорошо - после того, как вы пробрались через различные API и много узнали о XML-RPC , JSON-RPC , SOAP , REST, я пришел к выводу, что этот тип API звучит. Фактически, обмен стеками в значительной степени использует этот подход на своих сайтах, и я думаю, что эти люди знают, что они делают с помощью API-интерфейса Stack Exchange .


Answers

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

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

Зачем?

Поскольку вы знаете, что GET будет извлекать данные из вашего api. Вы знаете, что POST добавит новые данные в вашу систему. Вы знаете, что PUT сделает обновления. DELETE удалит строки и т. Д. И т. Д.

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

Я использую PHP, поэтому я использую function_exists (я думаю, его вызвал). Если функция не существует, я бросаю 405 (МЕТОД НЕ ДОПУСКАЕТСЯ).


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

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  

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


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

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

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

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

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

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

Обновить:

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

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

a = 4;

A ++;

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


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

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

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

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

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

Source


Я что-то упускаю?

Да. ;-)

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

note Примечание. Единое ограничение интерфейса важно, если вы хотите отделить клиентов от службы. Он похож на определение интерфейсов для классов, чтобы отделить их друг от друга. Ofc. здесь унифицированный интерфейс состоит из таких стандартов, как HTTP , MIME-типы , URI , RDF , связанные словари данных , гидра vocab и т. д.


Вы спросили :

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

Из Википедии в REST :

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

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

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

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

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

Вы спросили :

Я что-то упускаю?

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

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


Вот простое правило:

PUT для URL-адреса следует использовать для обновления или создания ресурса, который может быть расположен по этому URL-адресу.

POST для URL-адреса следует использовать для обновления или создания ресурса, который находится на каком-то другом («подчиненном») URL-адресе, или не может быть найден через HTTP.





php json api rest soap