У нас есть серия служб REST, которые извлекают ресурсы по идентификатору, но нам недавно поручили передавать параметры раскрытия для сохранения с помощью аудита.REST Best Practice GET с параметрами контекста
Какая польза будет ...
GET entity/{id}
Теперь превращается в нечто вроде ...
GET entity/{id}?requestName=&requestingOrganization=&reasonForUse=&verificationMethod=&otherAuditDisclosureProperties....
состояние entity не изменяется и по-прежнему идемпотентна однако мы должны проверять дополнительные информацию с каждым звонком для ее предоставления.
Сначала мысль заключалась в том, чтобы построить тело, но это не показалось правильным для GET. Это второй подход с использованием параметров запроса, которые не имеют намерения запрашивать/фильтровать. Эти дополнительные параметры - это действительно контекстная информация, захваченная в точке запроса. Они эквивалентны атрибутам SAML в SOAP-вызове, которые живут вне тела SOAP (что заставляет меня думать о возможных атрибутах заголовка).
Также обратите внимание, что эта информация передается так, что предоставленный токен аутентификации предназначен для вызова пользователя службы, а не фактического идентификатора контекста. Идентификация исходного вызывающего объекта неявно доверяется окружению доверия.
Как вы бы описали этот глагол/путь?
Могут ли эти параметры быть выведены сервером или они должны быть определены клиентом? Являются ли эти параметры для запроса или могут быть глобальными для клиента (как в архитектуре клиент/сервер) или учетной записью клиента? –
К сожалению, у сервера нет этой дополнительной информации, и они предназначены для каждого запроса. В принципе, я могу запросить тот же ресурс, но по другой причине (которую мы должны взять). – RailRhoad
Является ли клиент и сервер одной и той же корпорацией? можете ли вы предоставить больше информации о проблеме, которую вы пытаетесь решить? а не решение ... что кажется ужасным. Как вы гарантируете правильное использование причин для вызова службы? Как клиент, зачем мне это делать?Вы ставите большую нагрузку на мою сторону. Я бы не использовал такой API или не сообщил о причинах, как вы ожидаете. Слишком много работы. Если вы предоставите больше информации по этой проблеме, я бы предложил лучший подход. –