我正在考虑我计划构建的Web应用程序的体系结构，我发现自己在思考应用程序的核心部分。因为我想创建一个Android应用程序来访问它，所以我已经在考虑使用API了。
鉴于我希望从第一天开始就为我的应用程序提供外部API，最好将该API用作接口层（web）和应用程序业务层之间的接口吗？这意味着即使我的应用程序的主界面也会通过API访问数据。这种方法的缺点是什么？性能
更一般地说，如果构建一个可能需要以不同方式访问的Web应用程序，将API（Web服务）作为接口之间的接口是一种很好的架构设计图层和业务层？ REST是一个很好的“工具”吗？
答案 0 :(得分：7)
听起来你有两个问题，所以我的答案分为两部分。
首先，您应该在界面层和业务层之间使用API吗？这当然是一种有效的方法，我在当前项目中使用的方法，但你必须自己决定好处，因为只有你知道你的项目。可能需要考虑的最大因素是是否有足够的不同客户端访问业务层以证明开发API的额外开发工作是合理的？通常，这仅仅意味着超过1个客户端，因为当您发布更改或错误修复时，拥有API的好处将是显而易见的。还要考虑增加的复杂性，额外的代码维护开销以及分离界面和业务层可能带来的任何好处，例如提高可测试性。
其次，如果您实现API，您应该使用REST吗？ REST是一种体系结构，它尽可能多地说明了应用程序的其余部分是如何开发的。在API级别定义资源并不能转换为业务层。当您希望许多人能够针对您的API（例如NetFlix）进行开发时，休息往往是一种很好的方法。就我目前的项目而言，我们已经选择了基于HTTP的XML，因为我们不需要Rest通常提供的好处（或SOAP就此而言）。
一般来说，经验法则是实施最简单的解决方案，而不用将自己编入角落，为今天的要求而不是明天的要求而开发。
克里斯
答案 1 :(得分：4)
如果您要通过Internet从本机客户端访问它，您肯定需要一个Web服务层。
显然有很多方法和解决方案可以实现这一点但是我认为正确的架构指南是在服务器上有明确定义的服务接口，可以通过网关访问在客户端上。然后，您将使用POCO DTO （普通旧DTO）在端点之间进行通信。 DTO的主要目的是通过网络提供Web服务的最佳表示，它还允许您避免必须处理序列化，因为它应由客户端网关和服务接口库透明地处理。
这实际上取决于你的项目/应用程序如何变大，你是否想要通过努力将你的DTO映射到客户端和服务器域模型。对于大型应用程序，一般方法是在客户端将您的DTO映射到您的UI模型并让您的UI视图绑定到它。在服务器上，您将您的DTO映射到您的域模型，具体取决于服务的实施情况。
REST 是一种体系结构模式，对于小型项目，我认为是额外的开销/复杂性，因为与RPC / Document Centric Web服务相比，它不是一个好的编程适合性。在很多的话中，REST的一般概念是围绕资源开发您的服务。这些资源可以具有您的Web服务应提供的多种表示形式，具体取决于HTTP客户端指示的首选Content-Type（即HTTP ACCEPT HEADER）。您的Web服务的规范URL也应该在逻辑上形成（例如/ customers / reports / 1而不是/ GetCustomerReports？Id = 1）并且您的Web服务理想情况下将返回“客户端可以输入的有效状态”列表。响应。基本上，REST是一种很好的方法，可以促进松散耦合的体系结构和重用，但需要更多的努力来“遵守”基于标准的基于RPC / Document的Web服务，这些服务的好处不太可能在小项目中显现。
如果您仍在评估应使用的Web服务技术，则可能需要考虑使用我的open source web framework，因为它已针对此任务进行了优化。用于定义Web服务接口的DTO可以在客户端上重复使用（通常不是这种情况），以提供强类型接口，其中为您进行所有序列化。它还具有以下额外的好处：使您创建的每个Web服务都可以自动调用SOAP 1.1 / 1.2，XML和JSON Web服务，而无需任何额外配置，因此您可以为每个客户端方案选择最佳端点，即Native Desktop或Web App等
答案 2 :(得分：2)
我最近的偏好（基于J2EE6）是在会话bean中实现业务逻辑，然后根据需要添加SOAP和RESTful Web服务。添加粘合剂以围绕这些会话bean实现Web服务非常简单。这样我就可以提供对特定用户应用程序最有意义的服务。
答案 3 :(得分：1)
我们在项目上做了类似的事情。我们的Web服务主要进行标准内容管理，具有高比例的读取（GET）到写入（PUT，POST，DELETE）。因此，如果您的逻辑层相似，这是一种非常合理的方法。
在一个案例中，我们在Android上有一个视频播放器应用程序（摩托罗拉Droid，Droid 2，Droid X，...），它由云中的一组REST Web服务支持。这些会显示视频点播内容目录，启用视频会话设置和拆卸，处理书签等。 REST很好地解决了这个问题。
对于我们来说，REST的一个主要优势是可伸缩性：由于RESTful GET响应可以缓存在HTTP基础结构中，因此可以从同一个Web应用程序中提供更多客户端。
但REST似乎并不适合某种业务逻辑。例如，在一个案例中，我将日常维护操作包装在Web服务API之后。使用什么动词并不明显，因为此操作从远程源读取数据，用它来执行大量创建和更新本地数据库，然后删除旧数据，然后关闭并告诉外部系统做的事。所以我决定将它作为POST，使这部分API非RESTful。即便如此，通过在此操作之上设置Web服务层，我们可以在计时器上运行每日脚本，运行它以响应某些外部事件，和/或将其作为更高级别工作流程的一部分运行。
由于您使用的是Android，请查看Java Restlet Framework。有一个Restlet edition supporting Android。 Overstock.com的工程总监几年前对我说了很多，他告诉我们的一切都是真的，这是一个非常好的框架，让事情变得简单。
答案 4 :(得分：0)
当然，REST可以用于此。但首先要问问自己，这有意义吗？ REST是一种与其他工具一样的工具，虽然它是一款优秀的工具，但并不总是最好的锤子。 RESTful构建这个接口的优点是，IMO，它将在未来更容易创建这些数据的其他用途 - 也许你还没有想到的东西。如果您决定使用REST API，那么下一个问题是，它会说什么语言？我发现AtomPub是进程/应用程序交换信息的好方法 - 它非常易于扩展，因此您可以添加大量自定义元数据，但仍然可以使用任何Atom库进行解析。微软在其云[Azure]平台中使用AtomPub在数据生产者和消费者之间进行交流。只是一个想法。