api - 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)

在介绍之后是我的问题:

这是API的好用处吗

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

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

编辑

附加问题:

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

使用这种方法

可能会出现哪些我没有考虑到的潜在问题

Answer 1

第一件事。

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

话说回来...

这是否很好地使用了 API

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

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

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

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

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

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

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

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

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

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