我目前正在开发一个非常简单的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)
介绍之后我的问题是：
修改
其他问题：
答案 0 :(得分：17)
首先要做的事情。
询问设计（或实际上是什么）是否“好”取决于你如何定义“善”。典型的标准是性能，可维护性，可伸缩性，可测试性，可重用性等。如果您可以添加一些上下文，这将有所帮助。
说完了......
是否善用API
将业务逻辑与表示逻辑和数据持久性逻辑分离出来通常是个好主意。你的设计就是这样，因此我很乐意将其称为“好”。你可能会看一个正式的设计模式来做到这一点 - 模型视图控制器可能是当前的默认设置，尤其是。用于Web应用程序。
通过API运行整个网站是个好主意
嗯，这取决于应用程序。完全可以在Javascript / Ajax中编写应用程序，但是存在浏览器兼容性问题（尤其是旧版浏览器），并且您必须为用户通常期望的Web应用程序提供支持，例如深层链接和搜索引擎友好性。如果你有一个考虑周全的API，你可以在服务器上进行一些页面生成，如果这样可以更容易。
我有什么选择进行安全身份验证，使用API（出于某种原因，我不想使用HTTPS）
棘手的 - 使用这种应用程序，您必须区分对用户进行身份验证和验证应用程序。对于前者，OpenID或OAuth可能是主要的解决方案;对于后者，请查看Google如何要求您注册使用他们的Maps API。
在大多数Web应用程序中，HTTPS不用于身份验证（证明当前用户是他们所说的人），而是用于加密。这两者是相关的，但绝不等同......
我没有考虑的任何其他方法
也许这更符合问题5 - 但根据我的经验，API设计是一项相当深奥的技能 - API设计师很难能够准确预测API的客户端将需要什么。我会认真考虑在没有API的情况下为您的第一个客户端平台编写应用程序，并稍后将API分解出来 - 这样，您只需在第一个版本中构建所需的内容。
使用此方法可能会出现哪些我未考虑的潜在问题
版本控制与API有很大关系 - 一旦你创建了一个界面，你几乎永远不会改变它，特别是对于你无法控制的多个客户端。我将构建版本作为一流的概念 - 使用RESTful API，您可以将其作为URL的一部分。
答案 1 :(得分：-2)
这是否适用于API
取决于您将对该应用程序执行的操作。
通过API运行整个网站是个好主意
不，因此您的网站只能通过您的应用访问。这种方式此实现会阻止与其他浏览器的兼容性
我使用API有什么安全身份验证选择（出于某种原因我不想使用HTTPS）
您可以使用omniauth
我没有考虑的任何其他方法
创建两个前端，一个在您的应用程序中，另一个在常见浏览器中
使用此方法可能会出现哪些我未考虑的潜在问题
我现在不知道你的想法，但我看不出重大危险。