JSON против формы POST - PullRequest
Новая
       11

JSON против формы POST

36 голосов
/ 22 декабря 2011

У нас немного обсуждается вопрос публикации данных в конечной точке REST. Поскольку объекты довольно сложны, самое простое решение - просто сериализовать их как JSON и отправить в теле запроса.

Теперь вопрос такой: это кошерный? Или JSON должен быть установлен как параметр формы, такой как data = [JSON]? Или же отправка JSON в теле запроса просто не одобряется для того, чтобы заставить клиентов, использующих приложение, отправлять их данные через JavaScript вместо того, чтобы позволить браузеру упаковать их как application/x-www-form-urlencoded?

Я знаю все три варианта Работа . Но какие ОК ? Или хотя бы рекомендуется ?

Ответы [ 3 ]

25 голосов
/ 22 декабря 2011

Я бы сказал, что оба метода будут работать хорошо важно, чтобы вы оставались последовательными в своих API. Опция, которую я лично выбрал бы, это просто отправить контент как application/json.

POST не заставляет вас использовать application/x-www-form-urlencoded - это просто то, что часто используется, потому что это то, что используют веб-браузеры.

6 голосов
/ 09 декабря 2014

Нет ничего плохого в том, чтобы отправить его напрямую в виде сериализованного JSON, например, google делает это по умолчанию в своей библиотеке volley (что, очевидно, является рекомендуемой библиотекой REST для Android ).

Если так, на SO много вопросов о том, как не использовать JSON, а выполнять "нормальные" POST-запросы с залпом. Это немного противоречит интуитивно понятным новичкам, которым приходится переписывать метод базового класса 'getParams().

Но Google, имеющий собственную REST-библиотеку, которая делает это по умолчанию, будет моим показателем того, что это OK .

2 голосов
/ 18 октября 2017

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

OP должен поддерживать ввод JSON, поскольку он должен поддерживать сложное структурное содержимое.Тем не менее, подумайте об этом следующим образом: вы делаете запрос на выполнение какого-либо действия или просто отправляете данные, которые в основном document , и вы просто используете операцию POST в качестве эквивалента createновая запись.

В таком случае у вас есть в основном конечная точка ресурса с семантикой CRUDL.Следуя этому, вы на самом деле не ограничены application/json, но любым типом, который должна обрабатывать конечная точка ресурса.

Для конечных точек, не связанных с ресурсами

Я считаю, что (специально для JAX-RS) application/x-www-urlencoded лучше.

  1. Согласованность с OAuth 2.0 и OpenID Connect, они используют application/x-www-urlencoded.
  2. Легче комментировать отдельные поля с помощью аннотаций Swagger
  3. Swagger предоставляет больше значений по умолчанию.
  4. Почтальон генерирует удобную форму для заполнения и упрощает тестирование.

Примеры конечных точек, не связанных с ресурсами:

  • Аутентификация
  • Авторизация
  • Простой поиск (хотя я бы использовал GET на этом)
  • Не простой поиск, где многокритерии
  • Отправка сообщения / документа (хотя я бы также рассмотрел multipart/form-data, чтобы я мог передавать метаданные вместе с контентом, но у JAX-RS нет стандарта для этого Джерси, а у RestEasy есть свои собственныеimplementatioнс)
...