那么我以为我甚至可以通过这个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)
编辑
其他问题：
解决方法
询问设计(或事实上是什么)是“好”取决于你如何定义“善良”.典型的标准是性能,可维护性,可扩展性,可测试性,可重用性等.如果您可以添加一些上下文,这将有所帮助.
话说回来…
这是API的好用处
将业务逻辑与演示逻辑和数据持久性逻辑分开是一个好主意.你的设计是这样做的,所以我很高兴称之为“好”.您可能会看到正式的设计模式来执行此操作 – 模型视图控制器可能是当前的默认设置,尤其是.用于Web应用程序.
通过API运行整个网站是个好主意
那么这取决于应用程序.完全可以在Javascript / Ajax中完全编写应用程序,但是存在浏览器兼容性问题(特别是对于旧版浏览器),而且您必须为用户通常期望的Web应用程序(如深层链接和搜索引擎友好性)提供支持.如果您有一个很好的API,您可以在服务器上进行一些页面生成,如果这样更容易.
我有安全认证的哪些选择,使用API(由于某些原因我不喜欢使用HTTPS)
棘手的一个 – 使用这种应用程序,您必须区分认证用户和认证应用程序.对于前者,OpenID或OAuth可能是主要的解决方案;对于后者,请查看Google要求您注册使用Google Maps API.
在大多数Web应用程序中,HTTPS不用于身份验证(证明当前用户是他们说的是谁),而是用于加密.两者是相关的,但绝对不等同于…
我没有考虑过的任何替代方法
也许这更符合问题5 – 但在我的经验中,API设计是一个相当深奥的技能 – API设计师很难准确预测API的客户端需要什么.我会认真考虑编写应用程序,而不需要为您的第一个客户端平台提供API,并且稍后再考虑API – 这样,您只需在第一个版本中构建所需的内容.
使用这种方法可能出现的一些潜在问题是什么？
版本控制是一个很大的API – 一旦你创建了一个界面,你几乎永远不会改变它,特别是对于你不能控制的多个客户端.我将构建版本控制作为一流的概念 – 使用RESTful API,您可以将其作为URL的一部分.
