Можно ли изменить ответ в зависимости от параметров запроса GET?

Question

Было бы правильно, если бы ответы одной конечной точки имели другой набор полей?

Например:

Существует конечная точка - /orders, которая возвращает информацию о заказах(предположим - 42 поля), и эта информация отображается на веб-странице учетной записи пользователя.

В какой-то момент у нас есть другая веб-страница, которая нуждается (для своих собственных целей) в информации о заказах, которых нет у пользователязаплатил еще.Запрос будет выглядеть примерно так - /orders?unpaid=True В этом случае веб-странице нужно только 4 поля вместо 42. Должен ли я указывать в ответе только эти четыре поля, или лучше использовать один формат ответа для каких-либо целей?

Answer 1

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

Однако, похоже, вы намереваетесь использовать параметр запроса unpaid для дополнительной фильтрации всех платныхзаказы, поэтому в этом смысле можно указывать в качестве параметра запроса.

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

Поэтому я предлагаю следующий подход:

/orders                       -- always data with 42 fields
/orderSummaries               -- always data with  4 fields
/orders?unpaid=True           -- always data with 42 fields
/orderSummaries?unpaid=True   -- always data with  4 fields

, поэтому позвольте параметрам запросавлияет только на фильтрацию и сортировку набора результатов, но не на тип возвращаемых данных.

Answer 2

В большинстве случаев не стоит принимать решение на основе параметра запроса GET.GET-параметрами можно манипулировать без особых усилий.Сказав это, бывают случаи, когда я использую параметры GET, чтобы решить, что видит пользователь, и именно тогда я уже знаю, каков результат этого конкретного инцидента.Например, если пользователь вводит неверные учетные данные во время входа в систему, мой бэкэнд уже знает, что это неверно.Но скажем, у меня нет другого способа передать это сообщение об ошибке во внешний интерфейс для отображения пользователю.Тогда я бы сделал что-то вроде:

https://example.com/login.php?failed_message=Failed!No user found!

Мы не принимаем здесь никаких решений.Мы просто знаем, что если login.php вызывается с параметром GET, это должен быть неудачный вход в систему.Итак, мы перенаправляем на этот URL из бэкенда.