我正在使用的身份验证系统具有以下新功能：
1。验证系统允许用户指定与其进行交易的信赖方，
2。依赖方可以批准/拒绝/也许是请求（授权）-可能导致重定向到RP网站以解决RP的其他授权问题。
RP必须实施Auth系统指定的Web服务，以执行auth系统生成的批准/拒绝/也许请求。
我的问题是，作为REST服务，它看起来像什么。由于auth系统不能真正决定RP系统的URI样式，因此我想指定路径中没有任何参数，auth系统只需要知道服务的URI。请求的数据（用户名/ ID）可能在请求正文中有点json（建议POST http动词。GET可能还可以，但不愿意在URI中公开用户ID）。 auth系统不在乎RP如何处理请求数据，auth系统只希望“是/否/也许”答复（因此可能不是真正的GET / POST / PATCH / DELETE / etc范例）。
最好用什么动词？以及如何方便回复；它不是真正的成功/失败响应，因为查询有3种可能的结果，是否可以在响应中返回一些json（然后使用什么http谓词）？
我对此有些困惑。 GET似乎最明显
GET /api/user_link_authorize/{userid}
除非我被迫将用户ID放在URI中（我不想这样做）...
有什么建议吗？
答案 0 :(得分：0)
我的问题是作为REST服务的样子。
考虑一下网站的外观。
您将从书签列表中的一些已知URI开始。获取该页面将为您提供一种形式的表示形式，该形式将具有描述需要提供哪些数据的输入控件（并可能包括默认值）。客户提供它知道的数据，然后提交表单。表单中的数据用于创建HTTP请求，如HTML的表单处理规则所述。对于该请求的响应包括答案的表示形式，或者可能包括接下来要完成的工作。
那是REST。
（通过加标签的URI）检索表单当然是GET；我们只是更新表单“当前”表示形式的本地缓存副本。提交表单可以是GET或POST；我们不一定需要事先知道这一点，因为该信息是以表格本身的表示形式携带的。
GET与POST的权衡取舍。从语义上讲，GET是safe，这意味着可以随时获取资源，蜘蛛可以对其进行爬网，以这种方式访问资源是“免费的”。当资源空闲时，这很好，因为如果响应丢失，不可靠网络上的客户端可以自动重试请求。另一方面，在产生响应的成本实际上很高的情况下，向世界宣布请求是安全的，这并不是一个成功的选择。
此外，GET不支持消息正文（更确切地说，有效载荷没有定义的语义）。这意味着客户端提供的信息需要成为目标资源标识符本身的一部分。如果您要处理敏感信息，则可能会出现问题-不一定在传输过程中（可以使用安全套接字），但是一定要确保未将包含敏感信息的URI记录在敏感数据可能泄漏的地方。
POST支持在请求中包含有效负载，但不能保证查询是安全的，这意味着通用组件将不知道当响应丢失时它们是否可以自动重试请求。
鉴于您不希望URI中的用户ID，这是对GET的反对，因此赞成POST。