单端点而不是 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 在理查森的 model 中被标记为 0 成熟度，但是我无法解释为什么我应该将其更改为 3 级（或至少 2 级 - 资源和方法）。

Answer 1

大部分流量输入通过单个 HTTP GET 端点进入，其中有效负载被序列化和加密 (RSA)

这可能是一个问题，因为 HTTP 规范非常清楚带有有效负载的 GET 请求超出范围。

GET 请求消息中的有效负载没有定义的语义； 在 GET 请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。

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

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

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

适合您当前正在做什么的 HTTP 方法？ 邮政

---

REST（又名 Richardson Level 3）是全球 web 的建筑风格。

您的“一切都是单一资源的消息”方法放弃了许多使全球 web 灾难性成功的优势。

其中最明显的是缓存。 “Web 规模”之所以成为可能，部分原因是标准化的缓存支持大大减少了我们需要进行的往返次数。 但是，HTTP 中的缓存颗粒是资源——所有内容都与请求的目标 uri 无关。 因此，通过单个目标 uri 共享所有信息，您将失去细粒度缓存控制。

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

总而言之，您采用了一个相当智能的应用程序协议并削弱了它，给自己留下了一个传输协议。

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

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