单端点而不是 API - 缺点是什么？

Question

我有一个通过 HTTP 公开的服务。大多数流量输入通过单个 HTTP GET 端点进入其中，其中有效负载被序列化和加密 (RSA)。客户端系统有共同的代码，保证了序列化和反序列化的成功。编码参数之一是操作类型，在我的服务中有一个巨大的 switch（几乎 100 cases）检查执行了哪个操作并执行正确的代码。

        case OPERATION_1: {
            operation = new Operation1Class(basicRequestData, serviceInjected);
            break;
        }
        case OPERATION_2: {
            operation = new Operation2Class(basicRequestData, anotherServiceInjected);
            break;
        }

端点有几种类型，其中一些是典型的资源端点（GET_something、UPDATE_something），一些是基于方法的（VALIDATE_something、CHECK_something).

我正在考虑重构服务的API，使其更加RESTful，尤其是在系统的基于资源的部分。为此，我可能会将端点拆分为适当的端点（例如 /resource/{id}/subresource）或类似 RPC 的端点（/validateSomething）。我觉得这样会更好，但是我对此无能为力。

问题是：重构解决方案的优势是什么，以及：当前解决方案的劣势是什么？

目前的解决方案将客户端与服务器分开，它是可扩展的（添加新的端点需要在公共代码中添加新的操作类型）并且很清楚，两个客户端使用两种不同的编程语言。我知道 API 在 Richardson 的模型中被标记为 0 成熟度，但是我无法解释为什么我应该将其更改为 3 级（或至少 2 级 - 资源和方法）。

Answer 1

Most of traffic input gets into it via single HTTP GET endpoint, in which the payload is serialized and encrypted (RSA)

这可能是一个问题，因为 HTTP 规范非常清楚 GET 请求的负载是 out of bounds.

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

可能值得花一些时间来检查一下，因为您现有的实施似乎有效，那么问题是什么？

这里的问题是互操作性 - 其他人控制的进程能否与您控制的进程成功通信？ HTTP 标准为我们的“自描述消息”提供了共享语义；当您违反该标准时，您将失去与您不直接控制的事物的互操作性。

这反过来意味着您不能自由地利用我们已经拥有的广泛支持 HTTP 的解决方案，因为您在您的案例中引入了这种不一致。

适合您当前正在做的事情的 HTTP 方法？ POST

REST（又名 Richardson Level 3）是万维网的架构风格。

您的“一切都是对单一资源的消息”方法放弃了许多使万维网取得灾难性成功的优势。

其中最明显的是caching。 “Web 规模”之所以成为可能，部分原因在于标准化的缓存支持大大减少了我们需要进行的往返次数。然而，HTTP 中缓存的核心是资源——一切都以请求的目标 uri 为关键。因此，通过单个目标 uri 共享所有信息，您将失去精细的缓存控制。

您还失去了安全请求语义 - 每条消息都隐藏在单一方法类型中，通用组件无法区分“有效只读”消息和请求源服务器修改其自身资源的消息。这反过来意味着你会失去预取，并在网络不稳定时自动重试安全请求。

总而言之，您采用了一个相当智能的 application protocol 并使其瘫痪，给自己留下了一个传输协议。

对于您的情况，这不一定是错误的选择 - 毕竟 SOAP 是一种东西，而且，您的服务似乎确实按原样工作？这意味着您目前不需要您放弃的功能。

这会让我有点怀疑，如果您不需要这些东西，为什么要使用 HTTP 而不是某些消息传递协议？

单端点而不是 API - 缺点是什么？

Single endpoint instead of API - what are the disadvantages?

rest

api-design