Я пытаюсь настроить (на данный момент) действительно простой веб-сервис. Под простым я подразумеваю лишь небольшой объем реальной работы на стороне кода. На самом деле у него есть только один метод/функция: клиент отправляет логин пользователя, а служба отвечает очень безопасной информацией о пользователе (для целей этого вопроса, скажем, день рождения пользователя).
У меня много вопросов, но пока мне интересно:
Я рассматриваю возможность использования двух версий этого метода. В первой версии клиент может сделать только общий запрос без переменной информации. Служба ответит днем рождения того, кто прошел аутентификацию в сеансе клиента. Во второй версии клиенту разрешено запрашивать любое имя пользователя (на самом деле, все, что он хочет) и возвращать либо день рождения, либо «Ничего не найдено» и т. д.
Применение обоих вариантов было бы таким, чтобы большинство разработчиков получали дату рождения текущего пользователя, чтобы ее можно было применить к этому сеансу. Чтобы расширить мой пример: пользователь входит в систему, разработчик хочет иметь возможность поздравить его с днем рождения, если это применимо. Владельцы службы/данных не хотят, чтобы клиент разработчика имел какой-либо доступ, реальный или концептуальный, к чему-либо о пользователе, даже к его логину, они просто хотят соответствовать цели разработчика, поскольку это действительно приятно. Разработчик не хочет нести ответственность за потенциальный доступ к чему-либо, он просто хочет быть милым.
Вторая версия доступна для некоторых групп поддержки пользователей. На самом деле им нужно искать даты рождения пользователей, которые звонят, чтобы они могли подтвердить, что пользователь достаточно взрослый, чтобы, скажем, арендовать автомобиль. Возможно, им даже придется искать нескольких пользователей, чтобы увидеть, кто из группы наиболее подходит для получения наилучшего предложения.
Итак, я думаю, главный вопрос, наконец, заключается в том, могут ли эти два метода существовать в одной и той же службе?
На данный момент протокол, скорее всего, будет основан на SOAP, а не на RESTful, поэтому просто иметь URL-адреса, которые разрешаются в одну и ту же службу, но просто предлагают разные методы, вероятно, не вариант.
В идеале мне нужен способ отображения операций в WSDL на основе ролей. Очевидно, что документация, предоставленная любой группе, будет отражать только операцию, подходящую для роли, но в идеале разработчик/клиент: а) не увидит никаких операций, которых им не следует и б) получит ответ того же типа за попытку использовать запрещенный ответ. поскольку они были бы несуществующими, и c) в идеале, получить упомянутую ранее ошибку, потому что для их роли операция действительно НЕ существует, а не потому, что служба приняла дополнительные меры предосторожности на случай, если клиент попытается (что он, К вашему сведению, но я не хочу, чтобы это был первый и единственный уровень запутывания).
Мне снится несбыточная мечта?
Быстрое дополнение
Я должен был быть более конкретным об этом, я понимаю. Когда я говорю «на основе ролей», я имею в виду учетные записи служб, а не учетные записи пользователей. Таким образом, в моей гипотетической ситуации, описанной выше, приложение пользовательской службы, которое было бы предназначено для запроса любого идентификатора пользователя, будет использовать для этого одну учетную запись службы с привилегиями, не проверяя роль агента, вошедшего в сеанс (что было бы сделано для доступа к приложению, очевидно, но не к сервису).
