1

我有一个面向服务的架构，所有客户端请求都有一个网关。我喜欢这个，因为网关很整洁，隐藏了所有“内部”服务，并充当调度程序和自制负载均衡器。

然而，由于我的设计，客户只知道“一个”资源。并且必须发送请求操作及其在 JSON 中定义的参数的消息。

{
    "operation" : "Login",
    "parameters" :
    {
         "username" : "John",
         "password" : "1234"
    }
}

我应该因为我的架构不是 RESTful 而感到难过吗？我没有像 REST 规定的那样利用 HTTP 吗？请批评。

4

2 回答 2

2

我不知道“悲伤”是否是正确的词，但支持 REST 的论据之一，特别是在“正确”使用 HTTP 实现时，它免费为您提供以下内容（取自 Fielding 的论文):

  • 客户端-服务器交互，将 UI 与数据存储分离
  • 无状态服务器，提高可靠性和可扩展性
  • 客户端缓存，减少一些网络流量
  • 统一接口，将实现与它们提供的服务解耦
  • 分层系统，其中每个组件只关注其下方或上方的那些
  • 代表导向，你从资源的角度思考
  • HATEOAS，您的应用程序本质上是在其中导航链接
  • 一个受约束的界面，带有少量动词（例如 GET、PUT、POST、DELETE 和其他大约 3 个）

当您使用 SOAP 或其他 RPC 解决方案而不是 REST 时，理论上您放弃了一些但不是全部的这些特性。您可能正在放弃客户端可缓存性，并且您正在按程序进行思考，并且您可能无法使用 RESTafarians 所利用的所有安全和幂等性条件。

RESTful 服务变得非常流行，这并非偶然。但这是否意味着您必须构建 RESTful 服务，或者非 RESTful 服务本质上更糟糕？我不这么认为。我已经为两家不同的公司做过几个 RESTful SOA，虽然我更喜欢 SOAP（现在看起来很笨重）和像你这样的本土 API（即使很优雅，也不是标准的），但我不喜欢diss 其他方法并将它们视为劣等。

如果您打算使用自己的 API，只返回 200 和 404，并使用 GET 完成所有操作，那么是的，您的 API 在概念上很简单，也许它对您来说可以正常工作。但是，如果您需要多种媒体类型，并且您有包含经常附加、删除、创建和更新的集合的持久存储需求，那么学习现代 RESTful API 设计至少会为您开辟新的思维方式。

底线是不要感到难过，也不要觉得你必须去 REST，因为其他人都在这样做。但优点是真实的，REST 不仅仅是炒作。

于 2011-07-26T05:04:50.317 回答
1

没有。基本上，您有一个使用 JSON 而不是 XML 的自制 SOAP 样式 RPC。

您可能会问是否值得用 JSON 而不是使用 SOAP 堆栈来重新发明它，但如果您使用 JavaScript，它可能比 SOAP 更容易使用，而且没有遵守 SOAP 标准/工具集的负担.

除此之外，对我来说似乎很好。

于 2011-07-26T04:39:57.900 回答