术语问题：介于SOAP和REST之间的API-它们的名称是什么？ 我对SOAP与REST的理解：

REST=JSON，简单一致的接口，允许您CRUD访问事物的“实体”抽象，这些抽象不一定是单个DB行，更简单的协议，没有正式强制的“契约”，例如端点返回的值可能会更改，但不应该更改

SOAP=XML，更复杂的接口，允许您访问可应用于实体的特定于“服务”的操作，而不允许您直接、正式地强制执行预先声明的“契约”，如WSDL，其中返回类型是预定义和正式的

这是一个大致正确的评估吗

混合的怎么样？ 如果是这样的话，我怎么称呼混合API呢

例如，如果我们有一个表面上看起来像REST API返回JSON的东西，没有定义WSDL或形式化的契约，但它不是让您访问系统管理用户、产品、评论等的“实体”，而是让您特定地访问服务和复杂操作/sendUserAnUpdate/1111，/makeCommentTextPurple/3333，/getAllCommentsByUserThisYear/2222没有全面报道

“服务”在内部已经存在，团队只需通过RESTAPI发布对它们的访问，这种访问是基于一个请求一个请求的

问题: “混合物”通常指的是什么？此外，可能是一个糟糕的API。有一个词来形容它吗？或者，我可以引用一个概念，让大多数开发人员理解我所指的内容，而不必说我上面所说的整个段落

它只是JSON SOAP API吗？一种基于服务的REST API你叫它什么

谢谢！ 谢谢

我对SOAP与REST的理解

这是一个大致正确的评估吗

没有

是一种体系结构样式，也就是说，是体系结构约束的协调集合。万维网是使用REST架构风格构建的应用程序的一个示例

是一种传输不可知的消息协议规范，基于

如果是这样的话，我怎么称呼混合API呢

我认为你在这里找不到权威术语。通俗地说，您可能会听到一个宽泛的术语WebAPI来描述非RESTful的HTTP api

---

整个空间都被污染了。

如果你看看那些所谓的REST API，你的观察可能看起来是正确的，尽管REST实际上是完全不同的东西。它描述了一种将客户机与服务器分离的方法，允许后者在未来发展而不破坏客户机。它与典型的Web页面交互非常相似，因为服务器将告诉客户端它需要什么，并且只对客户端触发的请求作出反应。在设计REST服务时必须非常小心，因为在引入变更时，很容易包含可能影响客户机的耦合，特别是在商业软件工程中的所有实用主义的情况下。斯特凡·蒂尔科夫（Stefan Tilkov）就REST做了一次精彩的演讲，与or一起，可以作为REST核心内容的介绍讲座

REST中的一般前提应该始终是，服务器告诉客户机他们需要什么，服务器期望什么，并通过链接向客户机提供选择。如果服务器希望从客户端接收数据，它将发送一个表单式表示，通知客户端它支持的各个字段，并基于表单中包含的各个元素的类型，客户端知道是选择一个还是多个选项，输入一些自由文本还是输入日期值等等。不幸的是，大多数试图模仿HTML表单的媒体类型格式仍然是草稿版本

如果你特别看一看，你可能会感觉到我指的是什么。表单中可能出现的每个元素都有很好的定义，以避免混乱并提高互操作性。这实际上是REST的最终目标，让一个客户端能够与大量其他服务交互，而不必明确地适应每个API

REST的美妙之处在于，它不局限于单一的表示形式，即JSON，事实上，在REST环境中几乎可以交换无限多种可能的表示格式。对于REST应用程序IMO来说，Plain application/json是一种糟糕的媒体类型，因为它不包含任何关于链接和表单的定义，也不描述可能在请求和响应中提供的某些字段的语义。缺乏语义描述通常会导致接收者期望从/api/用户接收数据时返回某些特定的用户数据，这些数据可能因主机而异。如果你浏览一下，你会发现一些媒体类型的格式，你可以用来传输用户信息 d数据和任何支持这些表示格式的客户端都能够与此enpoint进行交互，而不会出现任何问题。菲尔丁本人声称

RESTAPI应该将其几乎所有的描述性工作用于定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体类型定义扩展关系名称和/或支持超文本的标记。描述在感兴趣的URI上使用什么方法的任何工作都应该完全在媒体类型的处理规则范围内定义，并且在大多数情况下，已经由现有媒体类型定义

通过内容类型协商，客户机和服务器将协商支持和理解的表示格式。因此，问题不应该是支持哪一个，而是要支持多少个。API或客户端能够交换有效负载的媒体类型越多，就越有可能与其他参与者进行交互

大多数所谓的RESTAPI实际上只是通过HTTP公开的RPC服务，这些服务可能尊重也可能不支持某些HTTP操作。因此，HTTP只是一个传输层。很多人仍然相信，在现实中，脚本或进程通常不会也不应该关心URI是否包含动词。URI本身只是一个指针，当客户端对接收有效负载感兴趣时，它将遵循并调用该指针。我们人类对于URI本身在调用该URI后可能返回的内容也不太感兴趣。对于任意客户端也是如此。更重要的是，随URI一起发布的内容。在Web上，可以使用某些文本和/或链接关系名称对链接进行注释，这些名称设置了与当前页面相关的链接内容。它可能会提示客户机在解析整个响应之前可能会调用某些内容，因为客户机很可能也想知道这一点。i、 e.是这样一个链接关系名称，它向客户机提示这一点。如果存在某些特定于域的术语，则可以使用或重用或定义的扩展方案

REST环境中的整个交互类似于或遵循特定的流程，即由应用程序域协议定义的订购和支付产品，可以设计为状态机。因此，客户在整个过程中都会受到指导。它基本上只是按照服务器发出的订单进行操作，有一些选择可以中断流程，即在付款前取消订单

另一方面，如您所述，SOAP是一种基于XML的RPC协议，它重用HTTP的子集来交换请求和响应。当您在WSDL中更改某些内容时，大量客户机必须进行调整和重新编译的可能性非常高。SOAP甚至定义了自己的安全机制，而不是重用TLS，这需要客户端的显式支持。由于进程中可能保留的状态，您有一个一对一的通信模型，所以扩展SOAP服务并不是那么容易。在REST环境中，这只是在服务器之前添加负载平衡器，然后对服务器进行n次镜像的问题。负载平衡器可以将请求发送到任何服务器，因为

“混合物”通常指的是什么？此外，可能是一个糟糕的API。有一个词来形容它吗？或者，我可以引用一个概念，让大多数开发人员理解我所指的内容，而不必说我上面所说的整个段落

它只是JSON SOAP API吗？一种基于服务的REST API你叫它什么

在HTTP之上进行通信的API的通用术语是Web API或HTTP API IMO。也使用此术语。除了SOAP之外，它还列出了XML-RPC和JSON-RPC。我同意Voice的说法，但如果你问4个人关于正确使用的术语，你会得到5个答案。虽然每个人都同意各自的术语是方便的，但现实表明，人们对明确的分离并不感兴趣。看看这里，在这些问题上加上标记。不使用RESTful没有什么错，不过对于真正的RPC服务，应该避免使用REST这个术语。尽管我认为我们已经处于一个“休息”这个词无法从误用和滥用中拯救出来的境地

对于需要使用外部文档、附带自定义的非标准化表示格式或仅公开域对象的CRUD的内容，我将向其添加-RPC，因为这或多或少是它的核心。因此，如果API发送JSON，并且通过Swagger或其他一些外部文档记录了预期的表示，那么JSON RPC可能是最合适的名称

总结这篇文章，我希望我能解释一下REST到底是什么，以及你的观察是如何被那些务实的尝试所破坏的，不幸的是，这些尝试是彻底失败的。如果你改变

---

在他们的实现中，有多少客户端会崩溃？除此之外，您不能在开箱即用的情况下重用为API A实现的客户机与其他公司或供应商的API B交互，因此必须调整您的客户机，或者仅为该API创建一个新的客户机。这是真实的RPC，因此应该以某种方式反映在名称中，以提示开发人员未来的期望。不幸的是，恰当地命名事物的过程，特别是关于REST，似乎已经失去了。有一个很好但很小的团体试图传播真谛，比如Voice、Cassio和其他一些人，尽管这就像是在和风车搏斗。这里最好的建议是首先讨论命名约定和每位参与者对哪个术语的理解，然后就大家都同意的命名方案达成一致，以避免将来的混淆。

我不确定我是否完全理解您的答案-我的理解中哪一部分是不正确的？我理解REST不仅仅是一个API协议——但就您所看到的API端点而言，这通常是开发人员对SOAP vs REST的期望吗？还是我？请阅读。谢谢你抽出时间。真的拓宽了我对这些概念的理解，以及它们是如何结合在一起的。特别是关于“REST”和它的实际含义，v.s.我一直听到它所指的所谓RESTAPI。