Question

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

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

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

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

Answer 1

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

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

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

RESTful服务变得非常流行，而不是偶然的。但这是否意味着您有来构建RESTful服务，或者非RESTful服务本质上更糟糕？我不这么认为。我为两家不同的公司做了几个RESTful SOA，虽然我更喜欢SOAP（这些日子看起来很笨重），而且喜欢像你这样的本土API（即使优雅，不是标准的），我也不会不理会其他方法并将其视为次等。

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

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

Answer 2

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

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

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

单入口点的SOA的RESTfulness

2 个答案: