Web API 设计技巧

Question

我目前正在开发一个非常简单的 Web 服务，并认为我可以为此编写一个 API，因此当我决定在新平台上扩展它时，我只需编写解析器应用程序即可。也就是说，该 API 并不适用于除我以外的其他开发人员，但我不会限制对它的访问，因此任何人都可以在此基础上进行构建。

然后我想我什至可以通过这个 API 运行网站本身，原因有很多，比如较低的带宽消耗（在浏览器中生成的 HTML）和客户端缓存。重度 AJAX 似乎是一个更大的理由。

布局如下：

Server (database, programming logic)
|
API (handles user reads/writes)
|
Client application (the website, browser extensions, desktop app, mobile apps)
|
Client cache (further reduces server reads)

在介绍之后是我的问题：

1. API 这么好用吗
2. 通过 API 运行整个网站是不是一个好主意
3. 我有哪些安全身份验证选择，使用 API（出于某种原因，我不喜欢使用 HTTPS）

编辑

其他问题：

1. 我没有考虑过的任何替代方法
2. 使用这种方法可能会出现哪些我没有考虑到的潜在问题

Answer 1

首先要做的事情。

询问设计（或实际上任何东西）是否“好”取决于您如何定义“好”。典型的标准是性能、可维护性、可扩展性、可测试性、可重用性等。如果您可以添加一些上下文，这将有所帮助。

话说回来……

API这么好用吗

将业务逻辑与表示逻辑和数据持久性逻辑分开通常是个好主意。你的设计就是这样做的，因此我很乐意称它为“好”。您可能会查看一个正式的设计模式来执行此操作 - 模型视图控制器可能是当前的默认值，尤其是。用于网络应用程序。

通过API运行整个网站是不是一个好主意

嗯，这取决于应用程序。完全用 Javascript/Ajax 编写应用程序是完全可能的，但是存在浏览器兼容性问题（尤其是旧浏览器），并且您必须构建对用户通常期望从 Web 应用程序中获得的东西的支持，例如深度链接和搜索引擎友好性。如果你有一个精心设计的 API，你可以在服务器上进行一些页面生成，如果这样更容易的话。

我有哪些安全身份验证选择，使用 API（出于某种原因我不喜欢使用 HTTPS）

棘手的一点 - 使用这种应用程序，您必须区分验证用户和验证应用程序。对于前者，OpenID 或 OAuth 可能是主要的解决方案；对于后者，请查看 Google 如何要求您注册以使用他们的 Maps API。

在大多数 Web 应用程序中，HTTPS 不用于身份验证（证明当前用户就是他们所说的身份），而是用于加密。两者是相关的，但绝不是等价的……

我没有考虑过的任何替代方法

也许这更适合问题 5 - 但根据我的经验，API 设计是一项相当深奥的技能 - API 设计人员很难准确预测 API 的客户端需要什么。我会认真考虑为您的第一个客户端平台编写不带 API 的应用程序，然后再将 API 分解出来——这样，您只构建第一个版本中需要的内容。

使用这种方法可能会出现哪些我没有考虑到的潜在问题

版本控制对于 API 来说很重要 - 一旦您创建了一个接口，您几乎永远无法更改它，尤其是对于您无法控制的多个客户端。我将构建版本控制作为一流的概念 - 使用 RESTful API，您可以将其作为 URL 的一部分。

Answer 2

1. API 这么好用吗

   取决于您将使用该应用程序做什么。

2. 通过API运行整个网站是不是一个好主意

   不，因此您的网站只能通过您的应用程序访问。这种方式这种实现会阻止与其他浏览器的兼容性

3. 我有哪些安全身份验证选择，使用 API（出于某种原因我不喜欢使用 HTTPS）

   您可以使用omniauth

4. 我没有考虑过的任何替代方法

   创建两个前端，一个在您的应用程序中，另一个在常用浏览器中

5. 使用这种方法可能会出现哪些我没有考虑到的潜在问题

   我现在不明白你的想法，但我看不到重大危险。