2017-01-05 3 views
0

Я создаю успокоительный веб-сервис для создания и чтения отчетов, сделанных из приложения. При создании отчета можно добавить с ним конфиденциальную информацию, такую ​​как имя, номер телефона, почту и т. Д. После создания отчета он становится общедоступным с помощью той же веб-службы.Отремонтированный веб-сервис, частичный Разрешение на чтение

POST /report 
{ 
"name":"test", 
"email":"[email protected]", 
"report_contents":.... 
} 

возвращает 200 OK с:

{ 
"id":1, 
"report_contents":.... 
} 

и способу получения вышеуказанного отчета: GET/отчет/{REPORT_ID}

У меня есть другое приложение, с которым администратор может управлять отчеты, созданные с помощью предыдущего веб-сервиса. В этом приложении я хотел бы отобразить конфиденциальную информацию. Он использует следующий URL-адрес для получения конкретного отчета.

GET /report/{report_id} 

который возвращает 200 OK:

{ 
"id":1, 
"name":"test", 
"email":"[email protected]", 
"report_contents":.... 
} 

Теперь есть вопрос. Это тот же самый url. Возможно ли, традиционно или даже неплохо использовать один и тот же веб-сервис для обоих вызовов, но с ним какое-то управление CRUD, где в зависимости от роли пользователя часть информации не отображается/блокируется? Или было бы лучше сделать отдельный веб-сервис с ограничениями?

ответ

1

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

Если вы беспокоитесь об этом, я могу думать о двух вариантах:

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

  • /report/{report_id}?view=full
  • /report/{report_id}?view=restricted

Или вы могли бы также рассмотреть два суб-ресурсов, один под названием /report/{report_id}/full и один называется /report/{report_id}/restricted, а затем вы можете вернуть 40x код, когда пользователь не имеет правильное разрешение, с заголовком Location в качестве намека на то, где они могут выглядеть.

+0

То, что вы говорите, имеет большой смысл. Я забыл упомянуть, что я буду защищать API с помощью ключа API или Oauth2. Основываясь на роли, я верну все, что им разрешено видеть. – Terabyte

+0

Не является ли двусмысленность проблемой при определении модели для возврата? – Terabyte

+0

Неоднозначность где?Клиент REST должен иметь возможность принимать различные представления. – Joe

1

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

это какой-то псевдо-код.

if (loggedInUser != isAdmin(user)) 
    return new { id: 1, contents: "..." } 
else 
    return new { id: 1, name: "test", email: "[email protected]", contents: "..." } 

Лично у меня были бы разные области, которые бы делали разные вещи. Одна область, которая извлекает модель для всех. В другом это будет похоже на область администратора.

В одном районе, у вас есть