API 设计和身份验证注意事项答案

【问题标题】：API Design and Authentication ConsiderationsAPI 设计和身份验证注意事项
【发布时间】：2011-05-08 08:46:25
【问题描述】：

我有一个数据版本控制系统，在某些 RDBMS 中实现为时间点架构。我正在编写一个基于 servlet 的 API 来公开有关此数据的一些功能。 API 将向用户返回数据点，允许用户标记数据以进行删除，并允许超级用户接受或拒绝这些数据修改请求，这也是通过 API 调用完成的。

问题来了。我已经处理了一些大型且值得注意的 API，这些 API 具有非常多样化的功能集，其中所有 API 调用都是 HTTPS GET。这就是我打算这样做的方式。我知道我知道，在一个完美的世界里，如果你正在开发一个面向资源的产品，你应该设计一个实现为 REST 接口的 ROA。然而，客户真的希望有一个更加混合的 RPC 风格的界面，以提高可读性和低学习曲线。如果我在 GET 方面做所有事情以获取客户端想要的格式的 API 调用，这是一件坏事吗？以后有什么东西会回来咬我吗？对未来的 API 添加或维护有不良影响吗？如果这种方法存在一些明显的缺陷，客户可以毫不费力地转向另一个方向。

我不想只做 REST 并使用 GET/POST/etc http 动词的原因之一是较低权限的用户只能进行更改请求。这些会一直存在，直到更高权限的用户同意/拒绝它们。

示例调用： somehost/?Method=GetOutlierData&SiteId=112-1&TimeInterval=2011-01-01_00:00:00--2011-01-01_23:59:59&ValidDate=2011-02-01_12:00:00&ReturnType=RecordId&Requester=13&Password=secret&ApiKey=19483

回应：返回=0&RecordsIds=

另一个我不确定我提出的是否是个好主意的地方是身份验证。每个调用都包括调用用户的凭据（以强制执行角色——某些用户只能使用一些 API 功能）。 API 将仅处理来自白名单上主机的调用，因此 API 的设计意味着客户端将构建一个端点来路由其所有组织的请求，并且该端点将提供秘密 API 密钥以及所有 API 调用.这将防止用户将自己未经批准的调用直接发送到 API。他们将在内部实施一些速率限制和禁止功能，以防止有意和意外的 DoS。既然我们是通过 SSL 运行的，那么这是一种适当的处理方式吗？

示例调用： somehost/?Method=blah&...&Requester=13&Password=secret&ApiKey=1298593

【问题讨论】：

我认为你的意思是 SOA :)
我真的在想，理想情况下，这将是一个面向资源的架构 (ROA)，其中给定的 http 动词将确定资源是否会发生动作。然而，客户的整体要求使这变得困难。
明白了。我的错，把它回滚了。

标签： java api

【解决方案1】：

对于非幂等操作使用 GET 请求本身并没有什么“坏处”，例如 SOAP 对所有操作都使用 GET（或 POST？）。但是，某些 Web 浏览器会查看使用 GET 作为幂等的链接，并尝试为您预取它。如果该链接要在您的后端数据库上执行删除行，这当然是一件坏事。

【讨论】：

这是关于预取的一个非常好的观点。不过，这个 API 永远不会通过浏览器使用。我们还实施了审查系统，因此当有人想要删除某些内容时，必须先由超级用户签字。

【解决方案2】：

GET 请求是幂等的。他们很安全。

浏览器、机器人、爬虫都认为发送 GET 请求是安全的操作，不会删除或更改数据。

这违背了 HTTP 的设计。

在理想情况下，您要说服客户他想要 REST 服务。

要求任何非幂等调用是 POST 而不是 GET 的失败

【讨论】：

谢谢，我感觉好多了。是的，我真的更喜欢 REST，但因为普通特权用户只能通过 API 提交删除请求以供审查（而不是直接调用 REST 来立即对资源进行操作），这确实使模型复杂化。
@kmarks2 我认为打电话给DELETE Resourse/[id] 然后在确认后将其放入待删除列表中并没有那么糟糕。
好点。一个问题是（实际上有点傻），因为这是一个数据版本控制系统，事情被标记为过期而不是实际删除。每当使用“删除”一词时，人们实际上都会感到害怕。 API 调用的良好可读性对客户来说非常重要（同样，DELETE 会让客户和审核他们的人掉头发）。
@kmarks2 在您的 REST API 之上为客户提供某种手持抽象，在底层调用 PUT、GET、POST、DELETE。告诉您客户的技术人员DELETE 只是一个关键字。