Подтвердить что ты не робот

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

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

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

Я знаю, что все три варианта работают. Но все в порядке? Или, по крайней мере, рекомендуется?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Для конечных точек без ресурсов

Я нахожу, что (особенно для JAX-RS) лучше application/x-www-urlencoded.

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

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

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