好的做法:REST API作为接口层和业务层之间的接口？

我正在考虑我计划构建的Web应用程序的体系结构,并且我发现自己在思考应用程序的核心部分.因为我想创建一个Android应用程序来访问它,我已经在考虑拥有一个API.

鉴于我希望从第一天开始为我的应用程序提供外部API,使用该API作为接口层(Web)和应用程序业务层之间的接口是一个好主意吗？这意味着即使我的应用程序的主界面也会通过API访问数据.这种方法的缺点是什么？性能？

更一般地说,如果构建一个可能需要以不同方式访问的Web应用程序,那么将API(Web服务)作为接口层和业务层之间的接口是一种很好的架构设计吗？REST是一个很好的"工具"吗？

听起来你有两个问题,所以我的答案分为两部分.

首先,您应该在界面层和业务层之间使用API​​吗？这当然是一种有效的方法,我在当前项目中使用的方法,但你必须自己决定好处,因为只有你知道你的项目.可能需要考虑的最大因素是是否有足够的不同客户端访问业务层以证明开发API的额外开发工作是合理的？通常,这仅仅意味着超过1个客户端,因为当您发布更改或错误修复时,拥有API的好处将是显而易见的.还要考虑增加的复杂性,额外的代码维护开销以及分离界面和业务层可能带来的任何好处,例如提高可测试性.

其次,如果您实现API,您应该使用REST吗？REST是一种体系结构,它尽可能多地说明了如何开发应用程序的其余部分以及API.在API级别定义资源并不能转换为业务层.当您希望许多人能够针对您的API(例如NetFlix)进行开发时,休息往往是一种很好的方法.就我目前的项目而言,我们已经选择了基于HTTP的XML,因为我们不需要Rest通常提供的好处(或者SOAP就此而言).

一般来说,经验法则是实施最简单的解决方案,并且无需将自己编入角落,为今天的要求而不是明天的要求进行开发.

克里斯