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

Question

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

130

Итак, я просматривал некоторые статьи о создании 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. Мы можем легко сериализовать /deserialize через PHP json_encode() и json_decode() и делать все, что захотим, с этими данными, не имея дело с различными методами HTTP-запроса.

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

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

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

Stann 01 янв. 2011, в 05:24

Источник

4

Зачем использовать JSON? Что делать, если нет JSON, а это обычный GET?
Mike DeSimone 01 янв. 2011, в 06:01
1

Да. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9
Ignacio Vazquez-Abrams 01 янв. 2011, в 06:02

Теги:

php

json

rest

soap

api

7 ответов

37

Это вопрос безопасности и поддержки.

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

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

idempotent методы

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

Источник

markus 01 янв. 2011, в 07:15

1

Извините, но как работают PUT и DELETE идемпотентные методы? Они влияют на состояние сервера и его данных!
Mahmoud Al-Qudsi 01 янв. 2011, в 06:22
27

@Computer: выполнение того же самого PUT или того же самого DELETE приводит к тому же конечному состоянию. Вот что значит «идемпотент».
Ignacio Vazquez-Abrams 01 янв. 2011, в 06:26
4

Для большей ясности: операция F является идемпотентной, если ее одно приложение и несколько последующих приложений возвращают один и тот же результат. Точнее, F идемпотентен тогда и только тогда, когда F (x) = F (F (x)). Например, Удалить является идемпотентом, потому что когда вы удаляете элемент один раз или удаляете его несколько раз, результат тот же: элемент удаляется только один раз с помощью приложения удаления первого, и ничего не происходит во втором или третьем приложении удаления.
qartal 28 фев. 2016, в 18:17
1

Но с точки зрения создания, когда вы создаете новую запись с помощью команды create и снова вводите ту же команду, создается (вероятно) две записи (хотя обе отражают одну и ту же информацию).
qartal 28 фев. 2016, в 18:18
0

qartal - ваше функциональное определение идемпотента должно быть «F (X) = F (X) F (X)». Хороший способ выразить это все же.
Gerard ONeill 27 нояб. 2017, в 17:50
0

Джерард, ваше определение неверно. Картал есть. Функция идемпотентна, если F, примененный к результату F, примененному к X, равен F, примененному к X, поэтому F (X) = F (F (X))
Jason Carr 14 июнь 2018, в 16:19

Показать ещё 4 комментария

22

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

Neil Whitaker 21 янв. 2012, в 15:11

1

Мне действительно нравится, как краткое это объяснение. Спасибо @Neil!
SimplGy 07 март 2013, в 22:49
2

У меня была небольшая проблема с тем, чтобы обдумать это. Этот пост ( lornajane.net/posts/2013/… ) о том, что глагол должен исходить из HTTP-запроса, так что URI должен содержать только существительные, прояснил его немного для меня
icc97 23 окт. 2015, в 08:55

9

Вы спросили:

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

Из Википедии на REST:

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

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

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

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

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

Вы спросили:

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

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

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

Merlyn Morgan-Graham 01 янв. 2011, в 08:41

8

В отношении использования расширения для определения типа данных. Я заметил, что 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

Pawel Cioch 03 март 2014, в 19:22

4

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

Да.; -)

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

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

inf3rno 19 сен. 2014, в 22:36

0

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

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

Почему?

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

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

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

The Unholy Programmer 21 июль 2017, в 22:31

Ещё вопросы

Зачем использовать JSON? Что делать, если нет JSON, а это обычный GET?
Извините, но как работают PUT и DELETE идемпотентные методы? Они влияют на состояние сервера и его данных!
@Computer: выполнение того же самого PUT или того же самого DELETE приводит к тому же конечному состоянию. Вот что значит «идемпотент».
Для большей ясности: операция F является идемпотентной, если ее одно приложение и несколько последующих приложений возвращают один и тот же результат. Точнее, F идемпотентен тогда и только тогда, когда F (x) = F (F (x)). Например, Удалить является идемпотентом, потому что когда вы удаляете элемент один раз или удаляете его несколько раз, результат тот же: элемент удаляется только один раз с помощью приложения удаления первого, и ничего не происходит во втором или третьем приложении удаления.
Но с точки зрения создания, когда вы создаете новую запись с помощью команды create и снова вводите ту же команду, создается (вероятно) две записи (хотя обе отражают одну и ту же информацию).
qartal - ваше функциональное определение идемпотента должно быть «F (X) = F (X) F (X)». Хороший способ выразить это все же.
Джерард, ваше определение неверно. Картал есть. Функция идемпотентна, если F, примененный к результату F, примененному к X, равен F, примененному к X, поэтому F (X) = F (F (X))
Мне действительно нравится, как краткое это объяснение. Спасибо @Neil!
У меня была небольшая проблема с тем, чтобы обдумать это. Этот пост ( lornajane.net/posts/2013/… ) о том, что глагол должен исходить из HTTP-запроса, так что URI должен содержать только существительные, прояснил его немного для меня

zzzzBov · Accepted Answer · 2011-01-01T08-42-00.000Z

176

Лучший ответ

Идея RE presentational S tate T ransfer заключается не в доступе к данным самым простым способом.

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

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

Например:

GET: /cars/make/chevrolet

скорее всего, вернет список автомобилей Chevy. Хороший REST api может даже включать некоторые параметры вывода в querystring, например ?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 в db с соответствующими цветами. Я говорю скорее всего, поскольку REST api не обязательно должен быть напрямую связан с структурой базы данных. Это всего лишь интерфейс маскировки, так что истинные данные защищены (подумайте об этом как о accessor и mutators для структуры базы данных).

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

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

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

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

zzzzBov 01 янв. 2011, в 08:42

0

Спасибо за хорошее объяснение. Но как идемпотентность помогает нам в веб-разработке? почему мы должны заботиться об этом? возможно кеширование?
Stann 01 янв. 2011, в 07:46
3

@ И это сочетание нескольких причин: следование рекомендациям HTTP означает, что у вас (вероятно) будет меньше проблем с обратной совместимостью, когда что-то изменится; использование html-формы через POST предупредит пользователя о множественных отправках одних и тех же данных (это предотвратит неидемпотентную транзакцию); следование четко определенной передовой практике - это, пожалуй, лучшая практика. Отдых не определен с конкретной реализацией, что позволяет вам использовать его по своему усмотрению. Я бы предложил воспользоваться всеми кодами ошибок HTTP и методами запроса, но вы можете делать это так, как хотите
zzzzBov 01 янв. 2011, в 16:15
4

Таким образом, проблема с этим ответом (это достойный ответ, но не полный) заключается в том, что он не отвечает на главный вопрос, который он задал: почему вы используете HTTP-глаголы и URI, а не пользовательские данные JSON (возможно, какой-то Основанный на JSON синтаксис вызова API). Вы можете сделать свой собственный синтаксис JSON таким образом, чтобы он "немедленно ... представлял, что происходит с данными". Чего вы не можете сделать, так это легко использовать встроенные средства и сетевые слои поверх HTTP, как вы можете с API, который следует всем соглашениям REST. Не то чтобы мой ответ, конечно, идеален;)
Merlyn Morgan-Graham 02 янв. 2011, в 19:39
0

@Merlyn Morgan-Graham: Спасибо за этот комментарий :) «Что вы не можете сделать, так это легко использовать встроенные средства и сетевые слои поверх HTTP» - Есть ли какой-нибудь способ, которым вы можете расширить это?
Stann 02 янв. 2011, в 20:20
4

@Andre: примеры, используемые в вики, - это аутентификация, кэширование и согласование типов контента. Теперь, когда я больше об этом думаю, вы можете использовать их с интерфейсами в стиле RPC, но часто возникает искушение реализовать собственную систему с нуля или создать интеграцию с существующей системой. С REST вы можете использовать встроенную интеграцию и администрировать ее на веб-сервере. Это означает более слабую связь, что означает, что вам нужно реализовать меньше, и означает, что ваше приложение становится более гибким, чтобы изменять параметры в будущем с меньшим количеством кода и влиянием на тестирование.
Merlyn Morgan-Graham 02 янв. 2011, в 20:42
0

@Merlyn Morgan-Graham не стесняйтесь улучшать мой ответ с любыми дополнительными важными деталями. Я не знаю, что комментарии урежут это.
zzzzBov 03 янв. 2011, в 02:35
10

Вместо DELETE: / cars / old, как насчет GET: / cars / old, за которым следует DELETE? Таким образом, у вас есть две отдельно идемпотентные команды.
Neil 21 янв. 2012, в 13:38
3

+1; Я согласен, что это хороший ответ (я повторяю это снова для удовольствия и выгоды). POST: /cars/oldest заменой DELETE не имеет большого смысла. Что-то вроде - POST: /cars/oldest/delete Могут, хотя я думаю, что решение Нила мне нравится больше. Единственное преимущество, которое дает прямое удаление по сравнению с его решением get-id-delete-id, - атомарность. Я хотел бы получить четкое бизнес-обоснование с не надуманным сценарием, прежде чем реализовывать такую вещь. Вам не нужно поддерживать все глаголы на всех объектах / URL.
Merlyn Morgan-Graham 10 фев. 2012, в 06:52
1

@ MerlynMorgan-Грэм, ты меня поймал! я совершенно забыл добавить команду удаления обратно в POST: /cars/oldest , это был всего лишь пример того, как повторные вызовы к серверу могут вызвать другое состояние сервера, хотя в ретроспективе я бы никогда не открыл API, чтобы сделать POST Команды, PUT или DELETE для относительного адреса, такого как ./oldest вместо этого будут доступны с кодом состояния 302 Found и заголовком Location: /cars/123 .
zzzzBov 10 фев. 2012, в 14:03
0

Я думаю, что вы могли бы использовать заголовок Accept, чтобы определить, в каком формате возвращать данные.
Samuel Edwin Ward 12 апр. 2012, в 14:03
0

@SamuelEdwinWard, в то время как заголовок Accept может (и, вероятно, должен) быть установлен вместе с расширением файла, расширение файла не зависит от реализации. Любая библиотека AJAX, которая позволяет вам настраивать путь запроса, позволит вам указать тип, однако не все библиотеки поддерживают изменение заголовков. Отдых - это все о принципе KISS .
zzzzBov 12 апр. 2012, в 19:45
1

В то время как я никогда не утверждал, что взламывал REST, вы сами заявляли: «Идея передачи представительного состояния не в том, чтобы получить доступ к данным самым простым способом». Если библиотека AJAX не поддерживает указание заголовка Accept, не будет ли это рассматриваться как сбой библиотеки, так же как отсутствие поддержки метода HTTP DELETE будет считаться отказом библиотеки?
Samuel Edwin Ward 13 апр. 2012, в 02:55
0

@SamuelEdwinWard, я думаю, что GET: /foo/id/123.js более GET: /foo/id/123.js , чем GET: /foo/id/123 , однако я также сказал: «Отдых не определен с конкретной реализацией, что позволяет вам использовать его по своему усмотрению. " Использование заголовка для установки типа данных так же приемлемо, как и использование расширения файла.
zzzzBov 13 апр. 2012, в 03:06
0

@ Если вы хотите задать вопрос, сделайте это, нажав кнопку «Задать вопрос» в верхней части страницы. Комментарии не предназначены для расширенного обсуждения.
zzzzBov 22 июнь 2012, в 16:50
0

Еще раз, так как кто-то удалил мой комментарий:
Boris Ivanov 23 июнь 2012, в 16:49
0

Расширения .json и .xml хороши для визуальных целей, но чтобы оставаться HTTP-совместимым (чтобы клиенты могли указывать несколько форматов), вы должны основывать свой возвращаемый формат на заголовке Accept
Juan Mendes 12 апр. 2013, в 18:44
0

Разве спор между расширениями не противоречит принципу REST, согласно которому каждый ресурс должен иметь уникальный URI? При использовании расширений каждый ресурс получает несколько URI (по одному на формат, поддерживаемый API). Это разрешено в реализации REST?
kb. 19 янв. 2014, в 20:34
1

@kb, в отличие от SOAP, который является четко определенным протоколом, REST является шаблоном проектирования для передачи данных. Не существует установленных правил о том, как все должно быть структурировано.
zzzzBov 19 янв. 2014, в 21:53
0

@zzzzBov Ага, я думал, что в архитектуре / шаблоне REST основным принципом является то, что у каждого ресурса должен быть один идентифицируемый URI. Однако теперь я понимаю, что ограничение применяется только другим способом. Т.е. каждый URI ведет к конкретному ресурсу, но каждый ресурс может иметь более одного URI. Спасибо за разъяснение.
kb. 19 янв. 2014, в 22:17

Показать ещё 17 комментариев