单入口点SOA的RESTfulness

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

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

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

---

我应该因为我的建筑不宁静而悲伤吗？我不是像REST处方那样利用HTTP吗？请评论。

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

您可能会问，使用JSON而不是使用SOAP堆栈是否值得重新发明，但如果您使用JavaScript，它可能比SOAP更易于使用，而且不需要遵守SOAP标准/工具集

除此之外，我觉得还可以。

我不知道“sad”这个词是否正确，但支持REST的理由之一，特别是在“正确”使用HTTP时实现的理由是，它免费向您提供以下内容（摘自菲尔丁的论文）：

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

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

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

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

---

底线是不要感到悲伤，也不要因为其他人都在休息而感到必须去休息。但是优点是真实的，休息不仅仅是炒作。

不把我所有的服务都当作单独的和独特的URL来使用，就没有办法让我自己安心了，是吗？公开10个分布式服务肯定比公开一个并让其他9个位于防火墙后面更安全，对吗？REST有很多限制，但多个URL是其中之一，因为资源是通过URL建模的。谢谢。作为使我的上述服务更加RESTful的一个假设起点，您会改变什么？您是否会将相同的JSON发送到相同的登录服务，并从中获取要进一步处理的URL列表（即，表示客户端成功通过身份验证后可用的操作的链接）？连同哪个动词（即GET、POST、PUT或DELETE）一起使用哪个URL？这个问题对所有人都是开放的。你能举一些其他“服务”的例子吗？登录是更传统的RESTful服务在收到401后留给浏览器去做的事情。关于登录，为了安全起见，我想到了一个模型，该模型在成功身份验证后将令牌授予客户端。此令牌将用于任何进一步的通信和操作。但是你的评论让我有点不确定。典型的客户端或浏览器会如何响应RESTful 401？RESTful系统有

POST host.com/orders

来创建订单（在描述新订单的实体中使用JSON或XML。服务器将创建和分配id并返回HTTP 201。另外，

GET host.com/orders

查看所有订单，使用查询参数搜索受限集，以及

GET host.com/orders/5

查看订单5。重新验证后，您可以设置浏览器以设置自己的浏览器响应401的登录框。