Rest SOA最常用的技术是什么？

我正在研究SOA概念，并找到了SOAP和REST（仅限于这些）技术（我应该这样称呼它吗？）。我想知道是否有其他技术（？）在这种情况下共存，它们代表什么。他们在某些方面更好吗？有很多人使用它们吗？等等。谢谢（：

首先，请阅读以下内容：

然后读一读：

归根结底，一切都在HTTP上。这是核心协议。你要问的至少是两件不同的事情。用XML、JSON或其他方式对文档（或参数）进行编码。传输内容的语义：不受HTTP约束或约束

XMLRPC-。这演变为SOAP。消息是XML格式的。语义是函数调用。消息包括方法和参数

SOAP-。消息以XML编码。它类似于XMLRPC，具有更多选项、更复杂的XML和正式的WSDL描述。

如果您使用JSON而不是XML，那么它就没有好名字。它是WS或REST和JSON。如果它使用XML，那么它就是唯一的SOAP

有两种常见的体系结构：SOAP风格的请求，其中任何动词都可以在请求中定义，而REST只有四个动词：POST、GET、UPDATE、DELETE，它们是HTTP请求的方法部分

---

REST-.您可以将任何消息编码与REST结合使用。有些人使用XML，有些人使用JSON或YAML。您可以轻松发明XML和JSON/YAML之外的其他表示法。但是，您必须使用四个规范动词。

将SOA架构与SOAP、REST和arch的其他实现分开是很重要的它的结构

您可以在任何支持通过消息请求和响应的技术之上实现SOA体系结构

SOA体系结构的核心特征是：-

• 客户端发送简单的请求消息
• 服务器使用单个回复消息进行响应
• 服务接口定义良好，并向客户端“公布”。即，客户端可以查询服务器支持哪些服务以及这些服务的接口是什么
• 没有数据复制，也没有本地存储。如果客户端想要了解小部件，那么它会查询小部件服务，客户端不会保留任何小部件数据。同样，如果客户端想要更新小部件的详细信息，它会向小部件服务发送更新请求
• 同步、异步和批处理接口都是可以接受的

作为一种体系结构，它的主要优势是：-

• 服务器与其客户机之间的唯一联系是“接口”。客户机完全不需要了解服务器的实现，同样，服务器也不关心客户机是如何实现的
• 数据由服务和仅由服务拥有和管理。这消除了同步和复制问题，并将双重更新的可能性降至几乎为零
• 结果架构的绝对简单性允许极大的灵活性
• 结果架构的绝对简单性使得系统非常可靠

然而，正如您在现实世界中正确总结的那样，大多数情况下使用SOAP和REST。当人们说SOAP时，他们通常指的是WS-*系列标准和协议-->WSDL（Web服务定义语言）、WSM（Web服务消息传递）、WS-Security等，它们使用SOAP作为传输机制

---

REST具有简单的优点，而WS*非常复杂且更难实现，我建议对任何相当大的系统使用WS*方法。WS*标准不仅支持简单的请求/响应，还支持http以外的异步消息和传输（JMS、文件等），而且，更重要的是，WS-security标准是完善的，支持安全的企业对企业通信。

如果您想了解WS-standards的最新情况，请使用WS*stack。

当您说“技术”时，似乎是指“协议”.是的，我不知道如何调用它们。但是REST不是一个协议。-。这是我的观点。在这个问题中，你混淆了很多东西。“我建议对任何合理的大型系统使用WS*方法”？为什么？Amazon.com的用户似乎更喜欢REST。所有这些似乎都离题了，因为问题是关于替代方案而不是建议。WS-*的设计太过复杂。拥有一套允许您做任何事情的协议是给已经复杂的系统增加复杂性的一个诀窍。与绝对简单化的概念完全相反y你之前做过广告。“数据由服务拥有和管理，只有服务。”你能提供这一点的参考吗？似乎与服务无状态正好相反，服务无状态被称为SOA原则。穆罕默德——如果你有“客户数据服务”，这是一个核心原则那么这就是你的客户数据来源。你不在本地存储这些数据（除了短期的查奇）而且您不会复制到其他数据库。@Muhammad--是的，WS*堆栈中有很多内容，但您只使用所需的部分。如果您从REST开始，并获得了对强身份验证或加密的新要求，您就陷入了困境，使用WS只需插入额外的部分即可。