【发布时间】:2010-01-08 21:47:19
【问题描述】:
我正在尝试建立一个(目前)非常简单的网络服务。简单来说,我的意思是它在代码方面只需要做少量的实际工作。它实际上只有一个方法/功能:客户端发送用户登录信息,服务以其他非常安全的有关用户的详细信息进行响应(就本问题而言,假设用户的生日)。
我有很多问题,但现在我想知道:
我正在考虑使用此方法的两个版本。在版本一中,客户端只能发出没有可变信息的通用请求。该服务将响应在客户端会话中通过身份验证的人的生日。在第二版中,允许客户端查询任何用户名(真的,任何他们想要的)并返回生日或“未找到”等。
提供两者的应用程序将使大多数开发人员能够获得当前用户的出生日期,以便将其应用于该会话。扩展我的示例:用户登录,如果适用,开发人员希望能够拥有“生日快乐”。服务/数据的所有者不希望开发人员的客户端对用户的任何内容(甚至他们的登录)有任何真实或概念的访问权限,他们只想满足开发人员的目标,因为这真的很好。开发人员不想对可能访问任何东西负责,他只想变得友善。
版本 2 可用于某些用户支持组。他们实际上需要查找打电话的用户的生日,以便他们可以确认用户的年龄足够大,比如说可以租车。他们甚至可能需要查找多个用户,看看谁最有资格获得最优惠的交易。
所以我想最后一个大问题是这两种方法是否可以存在于同一个服务中?
在这一点上,协议更可能是基于 SOAP 的,然后是 RESTful,因此简单地让 URL 都解析为相同的服务但只是提供不同的方法可能不是一种选择。
理想情况下,我需要的是一种基于角色在 WSDL 中显示操作的方法。显然,给任一组的文档将仅反映适合该角色的操作,但理想情况下,开发人员/客户将 a) 看不到他们不应该看到的任何操作,并且 b) 收到相同类型的响应以尝试使用禁止的响应因为他们会是一个不存在的错误,并且 c) 最理想的是,收到前面提到的错误,因为对于他们的角色,操作确实不存在,而不是因为服务采取了额外的预防措施,以防客户尝试(它会,仅供参考,但我不希望这是第一个也是唯一的混淆级别)。
我在做不可能的梦吗?
快速附录
我意识到,我应该更具体地说明这一点。当我说“基于角色”时,我指的是服务帐户,而不是用户帐户。所以在我上面假设的情况下,用于查询任何用户 ID 的用户服务应用程序将使用一个具有 privs 的服务帐户来执行此操作,而不是检查登录到会话的代理的角色(这将是显然是为了访问应用程序,而不是服务)。
【问题讨论】:
标签: web-services soap wsdl roles