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