Должен ли Rest API принимать POST-массив или строку JSON?

Я читал несколько учебников REST, и некоторые из них говорят, что для отправки данных в API для отдыха вам следует отправлять данные post в виде массива, что примерно так:

$data = array('foo' => 'bar');
$rest->post($data);

Тогда есть и другие, которые говорят, что вы должны отправить данные JSON следующим образом:

$data = array('foo' => 'bar');
$data = json_encode($data);
$rest->post($data);

Не уверен, есть ли стандартный способ сделать это, или если это нормально, но что обычно рекомендуется при разработке API?

ИЗМЕНИТЬ: Кажется, есть путаница. Чтобы уточнить, я согласен, что JSON следует использовать для потребления клиентов, но этот вопрос касается потребления SERVER. Смысл должен ли SERVER принимать данные JSON или POST от своих клиентов?

Ответ 1

Если вы создаете RESTful API, то есть ваше приложение является сервером и принимает запросы, тогда ваш вопрос кажется запутанным. Ваше приложение не будет отправлять какие-либо данные POST; клиенты будут отправлять вам данные POST.

С учетом сказанного возможно наличие API, который будет принимать JSON-кодированные запросы, хотя это действительно будет полезно только для очень нишевых сценариев. Подавляющее большинство клиентов будут получать данные POST для вашего API в формате application/x-www-form-urlencoded. PHP обрабатывает это за кулисами для вас и предоставляет данные в виде $_POST superglobal.

Если вы говорите об ответах на запросы POST и в каком формате вы должны использовать, это зависит от того, в каком формате клиент хочет, чтобы вы его отправили. Клиент либо укажет это в заголовке Accept или некоторые API-интерфейсы позволяют указывать URL-адрес (например, foo.com/some/thing/123.json или foo.com/some/thing/123/json). Клиент не обязан сообщать вашему приложению, какой формат он хочет, поэтому вам нужно выбрать разумный дефолт. Большинство API будут использовать JSON в эти дни.

Я никогда не слышал об API, который понимал сериализованный формат массива PHP, поэтому я не знаю, какие ресурсы вы читали, но я уверен, что вы неправильно поняли, что они предлагают.

Ответ 2

Собственно, я думаю, что это довольно хороший вопрос. не знаю, почему это произошло.

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

Если говорить, лично, я думаю, что лучше для серверной стороны использовать XML или JSON. Основная причина - валидация.

Проще проверить XML или JSON на схему. Также схема может быть обнародована, и хорошо спроектированная схема может описать вебсервис сама по себе. Клиент может даже использовать одну и ту же схему для проверки запроса до его отправки на сервер.

Передача кодированной с использованием URL-адреса также действительна, конечно. И также может быть проверена серверная сторона. Я думаю, по дороге, это просто вопрос предпочтения.

Кроме того, проверьте это обсуждение в SO, оно касается одной и той же темы:

JSON vs Form POST

Ответ 3

Вы должны подумать о клиентах, которые будут использовать API. Клиент HTML5\AJAX, скорее всего, захочет получить данные JSON, в то время как другие клиенты (Silverlight или собственные мобильные приложения) могут лучше потреблять XML.

Одна большая платформа\платформа для написания REST API выглядит как Microsoft Web API (на основе ASP.NET MVC). Продукт преуспевает в структуре WCF и позволяет пользователям писать REST API в среде MVC. Одна из особенностей заключается в том, что он выбирает поставщика сериализации на основе заголовка HTTP Accept.

Итак, если клиент принимает приложение /json, они работают со службой в JSON, и если accept XML они работают с сервисом в XML. Вы также можете написать свой собственный сериализатор объектов и подключить его к инфраструктуре.

Дополнительная информация: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/video-your-first-web-api

Ответ 4

В большинстве случаев вы хотели бы использовать данные POST, но я думаю, что получение json-данных действительно имеет свои применения, например, когда дело доходит до пакетных запросов.

API Facebook использует его.

Вам не нужно делать file_get_contents('php//input'). Из документации на facebook вы можете просто сделать что-то вроде этого:

curl -X POST "http://example.com/batch" -d 'batch = { "param": 1, "param2": "2" }'

Затем в PHP-коде, если вы используете PHP, вы можете получить его через параметр $_POST и сделать json_decode.

var_dump($_POST);

array(1) {
  ["batch"]=>
  string(30) "{ "param" : 1, "param2" : "2"}"
}

var_dump(json_decode($_POST['batch'], true));

array(2) {
  ["param"]=>
  int(1)
  ["param2"]=>
  string(1) "2"
}

Ответ 5

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

Ответ 6

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

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

Лично я выбираю получать все POST и PUT данные как JSON непосредственно в теле.

Ответ 7

Суть заключается в повторном использовании уже существующей реализации HTTP.

HTTP построен для принятия множества различных типов контента, и вам нужно только указать, что вы используете в заголовках .

Обновлен API REST, который принимает различные форматы и работает с заголовком содержимого. Вы можете отправлять значения x-www-form-urlencoded с веб-страницы HTML или делать запрос AJAX с помощью сырого JSON, и нет путаницы, если все следуют протоколу.

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

Многие фреймворки, разработанные со встроенными API-интерфейсами, обрабатывают самые популярные типы контента на более низком уровне. Они также могут кодировать данные ответа в соответствии с заголовком "Принять" .

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