gpt4 book ai didi

web-services - 什么时候不使用 REST API?

转载 作者:行者123 更新时间:2023-12-04 03:50:23 26 4
gpt4 key购买 nike

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题?更新问题,以便 editing this post 可以用事实和引用来回答它.

6年前关闭。




Improve this question




REST API 始终被视为基础设施用途。我不是专家,但我发现他们应该实现的原则涉及水平扩展和性能。它们应该抑制客户端和服务之间的各种关联(无 session 等)。很少从业务角度考虑 REST API。

上周,团队中有人提议将遗留应用程序的一部分实现为 REST API。此应用程序以前作为库 (.NET) 嵌入到每个请求它的应用程序中。 REST API 很快就遇到了性能问题(客户端和服务器之间的往返次数过多)。作为一种解决方法,实现了缓存(在服务器端)。在我看来,它违反了 REST 原则。如果没有缓存,我们应该为一个客户端提供许多服务器以获得可接受的性能,并带有并行请求或负载平衡器(或类似的东西......)。

当我们谈论 API 时,我认为此类 API 应该由业务需求驱动。 根据您的经验,是否存在不适合 REST 的业务用例?

[编辑] API 是关于模拟来自客户端的条目的工作流程......

最佳答案

As a workaround, caching was implemented (on the server side). In my opinion, it violates the REST principles.



实际上使用缓存是您必须遵循的 REST 约束。 Fielding论文5.1.4缓存: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_4我建议您在提出任何其他问题之前阅读整篇论文(或至少阅读 REST 部分)。

they are supposed to suppress all kinds of affinities between clients and services (no session, etc...).



无状态是将 session 移动到 REST 客户端,而不是您不能拥有 session 。如果您可以在客户端进行,您不想在服务器端维护那么多客户端 session 。这使得缓存更容易。

REST APIs are rarely considered from a business perspective.



我认为这就是大多数大公司拥有 REST API 的原因。例如。 facebook、google、twitter 等……这些 API 主要用于 3rd 方客户端。办公室。如果您的 API 将被公司中的许多客户使用,那么使用 REST 可以替代使用 SOA、其他 RPC 或消息代理解决方案。

Last week, someone in the team proposed to implement a part of a legacy application as a REST API. This application was previously embedded as a library (.NET) in every application that requested it.



REST 是关于构建客户端可以使用的应用程序接口(interface)(或交付方法),而不是关于构建应用程序。它的目的类似于 SOA 的目的以及我之前提到的其他事情。 DDD 是关于构建(大)应用程序的。

The REST API quickly suffered from performance issues (too many round trips between the client and the server). As a workaround, caching was implemented (on the server side).



在这种情况下,检查性能问题的原因可能是有益的。如果你发送一系列消息,因为 REST API 缺少一个特性,那么最好在 REST 服务中实现该特性,或者如果它是复杂的东西,不需要属于低级服务,那么你可以编写上层 REST 服务,它使用低层服务(又名分层系统约束)。如果问题是用户太多,那么ofc。缓存和水平/垂直缩放是解决方案。

When not to use REST APIs?



我不认为有这样的规则。您可以在将使用 SOA 或任何基于请求-响应的消息传递解决方案的任何地方使用 REST。我不认为它非常适合基于事件的消息传递,因此该技术有其局限性。在这种情况下,您可以使用轮询或服务器发送的事件来解决问题,或者您可以创建一个混合接口(interface),该接口(interface)通过 HTTP 使用 REST 用于 req-rep pat 和 (web)sockets 用于应用程序接口(interface)的基于事件的部分。

当您不想花钱为您的用户编写不同的客户端,或者您想要一个客户端开发人员可以用来与您的系统集成的界面时,REST 是一个理想的选择。例如。公共(public) facebook api,可供 fb 应用程序开发人员使用或批发商的私有(private) api,可供零售商的网上商店用于自动更改价格或订购产品以填充库存。

通过单个 HTML 页面 Web 应用程序,REST 可以很好地防止服务器端代码在客户端上的重复。例如。构建请求模板(URL、表单等)被移动到服务(又名 HATEOAS 约束)。因此,在浏览器中运行的客户端可以使用一些通用代码来构建基于例如 JSON-LD 响应的完整 HTML 页面。这个目前不常用。

关于web-services - 什么时候不使用 REST API?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32787192/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com