Как управлять свойством ответа на основе ролей в RestAPI?

Мы пытаемся реализовать RestAPI с контролем доступа пользователей, где один и тот же URI должен возвращать разные ответы для двух пользователей с разными ролями. Скажем, ответ на URI(/resource/123)

{
    "customer_name":"user_name", #String
    "location":"000", #String
    "age":30 #Int
    "has_submitted_tax":true #Boolean
}

Как скрыть каждое свойство на основе ролей.

Подход 1:

Скрытие узла, к которому пользователь не должен обращаться

Проблема: это нарушит структуру ответа. Клиент может сломаться, так как ожидаемый узел будет пропущен.

Подход 2:

Возвращает null для этого узла.

Проблема: это нарушит тип данных ответа. Поскольку «логический» узел будет иметь нулевое значение.

Подход 3:

Возвращает значение по умолчанию для этого узла.

Проблема: Здесь узел будет иметь некоторое значение, где существует равная вероятность того, что фактическое значение будет возвращено для узла (значение по умолчанию является фактическим значением).


json api rest response access-control
person Selvaraj    schedule 13.01.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

  1. Некоторые значения могут быть пустой строкой или
  2. значение маски равно xxx или
  3. поле может вообще отсутствовать (аналогично необязательным элементам в XML)

Это суммирует ваши 3 подхода. Пока клиент знает, какую стратегию вы выбрали, все в порядке.

Если вы применяете авторизацию к существующему API с большим количеством клиентов, которые ожидают определенного поведения, то лучше всего использовать маскированные значения, где значения заменяются значением по умолчанию. Риск заключается не столько в том, что значение по умолчанию может быть реальным, сколько в том, что конечный пользователь не узнает, что информация была замаскирована.

person David Brossard    schedule 15.01.2015