类似于 eBay 的 Web 门户 API 接口
https://stackoverflow.com/questions/1231532
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我们为 Graphics Job Work 开发了一个 B2B 门户网站，类似于 Camera Ready Art (www.camerareadyart.com)。它针对的是那些想要将位图转换为矢量图形、徽标设计和一般图像处理（如将黑白图像着色为彩色等）的人。
我们希望添加设施，以便人们（我们的客户）可以使用我们提供的一组 API 直接从他们的网站发布他们的作品，而无需直接访问我们的网站来发布他们的作品。
到目前为止，我从未做过这样的事情，所以我不知道如何实现这样的事情。我还想知道如何实现安全性，以便只有经过授权的人才能发布他们的作品？
谁能给我一些关于我们如何做这样的事情的想法。
解决方案
这个问题涵盖的范围非常大，我怀疑任何单一答案都可以涵盖细节。我能做的就是根据我所犯的错误提供一些起点。
在您自己的 API 之上构建
不要将 API 功能添加到现有系统中。这样做将会：
- 导致额外的测试负载（您必须独立测试您的应用程序和 API）
- 导致总体维护成本增加
- 导致 API 质量比您想要提供的要差
您的总体目标应该是首先构建 API，然后在您自己的 API 之上构建您的应用程序。这样做有以下好处：
- API 测试本质上是在测试您的应用程序时执行的
- 您不会“忘记”添加任何所需的 API 方法
您的应用程序和应用程序逻辑（API）将在逻辑上分离 - 它们之间在等式每一边的作用和负责的方面将有明确的分离。这将有助于指导发展。这还允许您在需要时非常轻松地将应用程序和 API 放置在不同的计算机上。
使用自己的 API 是非常重要的一点。您的 API 的设计最初并不是最优的，只有通过您自己使用它，您才能使其以有效的方式为人们提供实际需要的功能。
您最终将得到一个大致如下所示的系统：
------------- -------------
| | | |
| Your APP | <= HTTP communication => | Your API |
| | | |
------------- -------------
这凸显了一些进一步的好处：您可以将“您的应用程序”替换为任何其他应用程序，从而允许您的客户创建应用程序以最适合他们的方式处理事务。您还可以在现有 API 之上创建应用程序的新版本 - 迁移到公共网站的新版本会容易得多。
设计您的 URL：映射到类和方法
选择合理的 URL 与选择合理的类和方法名称一样都是一个问题。从类及其方法派生 URL 是一个好方法。如果 URL 和类/方法之间没有明显的相关性，从长远来看，您会发现事情很难维护。
我个人更喜欢通过以下方式将 URL 与类和方法关联起来：
- 将类映射到顶级目录
- 将方法映射到顶级目录的子目录
例子：
您的 API 的 URL 是 https://api.camerareadyart.com.
你有一个 image 对象与 toColour() 和 toBlackAndWhite() 方法。
这可能映射到：
https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/
类似地，位图到矢量的转换：
https://api.camerareadyart.com/bitmap/toVector/
设计回应
当有人从您的 URL 之一获取数据或将数据发布到您的 URL 时，会发生什么？如何处理错误，如何处理异常？回应采取什么形式？
我不能告诉你在这里做什么。就我个人而言，我更喜欢将事物尽可能地映射到 HTTP，然后仅在需要时超越此范围。
例如，如果传入请求被接受并被处理，但在内部遇到错误，我将发出 500 状态响应。同样，如果给定的 API 方法需要尚未提供的身份验证，我可能会发出 403。利用现有的 HTTP 功能可以让您不必重新发明某些东西。
使用 HTTP 的现有方面
除了明智地使用 HTTP 状态代码之外，请确保在推出自己的解决方案之前寻找仅 HTTP 的方法来执行某些操作。
希望用户指定响应格式是 XML 还是 JSON？使用 HTTP 接受标头。
想要将客户端重定向到不同的 URL 以获取请求的结果吗？使用 HTTP 位置标头。
HTTP 有许多功能已经可以处理您可能想做的许多事情。使用它们！
安全
这里有两个一般问题需要解决：对用户进行身份验证，并确定给定用户可以执行哪些操作。
安全：验证
用户需要在请求中指定他们是谁。
想到的第一个解决方案是允许用户指定用户名和密码，可能与他们用于访问您的应用程序的用户名和密码相同。这表面上看起来是个好主意，但并不理想。
用户最终会将他们的用户名和密码写入他们自己的应用程序中。不可避免地，一个用户会忘记他们的密码，并会更改密码，以便他们可以愉快地访问您的应用程序，并在此过程中破坏他们自己的应用程序。
更好的选择是用户提供身份验证令牌，该令牌本质上是用户唯一的单个值，就像用户名和密码合二为一一样。
这使您可以在逻辑上将用户名和密码与 API 访问分开。用户可以随时更改应用程序的用户名和/或密码，而不会中断对 API 的访问。
用户还可以拥有多个 API 令牌，每个令牌具有不同的访问级别，从而允许用户安全地将 API 令牌分发给第三方服务。
安全：访问控制
对于外界来说，你的 API 就是一组 URL。根据定义，每个 URL 都是唯一的，并且执行唯一的任务。围绕这些概念建立访问控制机制是一个很好的起点。
我更喜欢为每个令牌保留一个允许令牌访问的 URL 列表。当给定的令牌用于访问 URL 时，很容易知道正在访问哪个 URL 以及它是否在令牌的允许 URL 列表中。
如果您明智地选择一组 URL，其中每个 URL 执行一个唯一的操作，则此过程将为您提供您将获得的最佳级别的访问控制。
为了提供更精细的控制级别，您可能还需要指定允许令牌访问的每个 URL、允许它们使用哪些查询参数。
