REST API始终被视为基础结构目的。我不是专家，但我发现他们应该实现的原则涉及水平扩展和性能。他们应该压制客户和服务之间的各种亲和力（没有会话等）。从业务角度来看很少考虑REST API。
上周，团队中的某个人提议将遗留应用程序的一部分实现为REST API。此应用程序以前作为库（.NET）嵌入到请求它的每个应用程序中。 REST API很快就遇到了性能问题（客户端和服务器之间的往返次数太多）。作为一种解决方法，实现了缓存（在服务器端）。在我看来，它违反了REST原则。如果没有缓存，我们应该为一个客户端提供许多服务器以获得可接受的性能，并行请求或负载均衡器（或类似的......）。
当我们谈论API时，我认为这些API应该由业务需求驱动。根据您的经验，是否存在不适合REST的业务用例？
[编辑] API是关于模拟来自客户端的条目的工作流程......
答案 0 :(得分：10)
作为一种解决方法，实现了缓存（在服务器端）。在我的 意见，它违反了REST原则。
实际上使用缓存是一个必须遵循的REST约束。论文摘要5.1.4缓存：http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_4我建议你在任何进一步的问题之前阅读整篇论文（或至少是REST部分）。
他们应该压制客户和服务之间的各种亲密关系（没有会话等）。
无状态是指将会话移动到REST客户端，而不是您无法进行会话。如果可以在客户端进行，则不希望在服务器端维护那么多客户端会话。这使缓存更容易。
从业务角度来看很少考虑REST API。
我认为这就是为什么大多数大公司都有REST API的原因。例如。 facebook，google，twitter等...这些API主要面向第三方客户。 OFC。如果您的API将被公司中的许多客户使用，那么使用REST可以替代使用SOA，其他RPC或消息代理解决方案。
上周，团队中的某个人提议实施一部分 遗留应用程序作为REST API。此应用程序以前 在每个请求它的应用程序中作为库（.NET）嵌入。
REST是关于构建客户端可以使用的应用程序接口（或交付方法），而不是构建应用程序。它的目的类似于SOA的目的和我之前提到的其他内容。 DDD是关于构建（大）应用程序。
REST API很快就遇到了性能问题（太多了 客户端和服务器之间的旅行）。作为一种解决方法，缓存是 实现（在服务器端）。
在这种情况下，检查性能问题的原因可能是有益的。如果你发送一系列消息，因为REST API缺少一个功能，那么在REST服务中实现该功能是好的，或者如果它是复杂的，不一定属于低级服务，那么你可以写上层REST服务，它使用低级服务（也称为分层系统约束）。如果问题是用户太多，那么ofc。缓存和水平/垂直缩放是解决方案。
何时不使用REST API？
我认为没有这样的规则。您可以在任何使用SOA的地方或任何基于请求 - 响应的消息传递解决方案上使用REST。我认为它不适合基于事件的消息传递，因此该技术具有局限性。在这种情况下，您可以使用轮询或服务器发送的事件进行解决方法，或者您可以创建一个混合接口，该接口同时使用REST通过HTTP作为req-rep pat和（Web）套接字，用于基于事件的应用程序接口部分。 / p>
REST是一种理想的选择，当您不想花钱为用户编写不同的客户端，或者您希望客户端开发人员可以使用的界面与您的系统集成时。例如。公共facebook api，可供fb app开发者或批发商的私人api使用，零售商的网上商店可以使用它来自动更改价格或订购产品以填补库存。
通过单个HTML页面Web应用程序，REST可以很好地防止客户端上的服务器端代码重复。例如。构建请求模板（URL，表单等）被移动到服务（aka.HATEOAS约束）。因此，在浏览器中运行的客户端可以使用一些通用代码来构建基于例如JSON-LD响应的完整HTML页面。目前这种情况并不经常使用。