术语问题：API 介于 SOAP 和 REST 之间——它们的名称是什么？
Terminology question: API somewhere between SOAP and REST - what is the name for them?
我对 SOAP 与 REST 的理解：
REST = JSON，简单一致的接口，让您可以 CRUD 访问 'entities'（不一定是单个 DB 行的事物的抽象），更简单的协议，没有正式的强制执行 'contract'（例如，端点 return 的值可以更改，但不应该更改）
SOAP = XML，更复杂的接口，让你可以访问'services'（你可以对实体应用特定的操作，而不是让你直接对实体进行增删改查），正式强制执行，预先规定 'contract'（类似于 WSDL，其中 return 类型是预定义和形式化的）
这是一个大致正确的评估吗？
混合物怎么样？
如果是这样，我怎么称呼 API 是混合物？
例如，如果我们在表面层 看起来 像 REST API（returns JSON，没有 WSDL 或定义了正式的合同 - 但不是让您访问系统管理的 'entities'（用户、产品、评论等），而是让您访问服务和复杂操作的特定权限（/sendUserAnUpdate/1111、/makeCommentTextPurple/3333, /getAllCommentsByUserThisYear/2222) 没有完全覆盖？
'services' 已经在内部存在，团队只需按请求发布对它们的访问，否则看起来像 REST API。
问题：
通常指的 'mixture' 是什么（此外，也许是坏的 API）。有词吗？或者我可以参考的概念将使大多数开发人员理解我所指的内容，而不必说出我在上面所做的整个段落？
仅仅是“JSON SOAP API？”，“基于服务的 REST API？” - 你会怎么称呼它？
谢谢！
谢谢！
My understanding of SOAP vs REST
...
Is that a broadly correct assessment?
没有
REST 是一种“架构风格”，也就是说架构约束的协调集合。万维网是使用 REST 架构风格构建的应用程序示例。
SOAP is a transport agnostic message protocol specification, based on XML Information Set
If so, what do I call an API that is a mixture?
我认为您不会在这里找到权威术语。通俗地说，您可能会听到广义的术语“web api”来描述不是“RESTful”的 HTTP API。
整个space被semantic diffusion污染了。
如果您看一下所有那些所谓的 REST-API，您的观察可能看起来是正确的，尽管 REST 实际上是完全不同的东西。它描述了一个 architecture or a philosophy whose intent it is to decouple clients from servers, allowing the latter one to evolve in future without breaking clients. It is quite similar to the typical Web page interaction in that a server will teach a client on what it needs and only reacts on client-triggered requests. One has to be pretty careful and pendant when designing REST services as it is too easy to include a coupling that may affect clients when a change is introduced, especially with all the pragmatism around in (commercial) software engineering. Stefan Tilkov gave a great talk on REST back in 2014 that, alongside with Jim Webber or Asbjørn Ulsberg，可以用作介绍 REST 的核心内容的讲座。
REST 的一般前提应该始终是服务器教导客户端他们需要什么以及服务器期望什么，并通过链接向客户端提供选择。如果服务器希望从客户端接收数据，它会发送一个表单式的表示来通知客户端它支持的各个字段，并根据表单中包含的各个元素的 affordance 客户端知道是否select 一个或多个选项，输入一些自由文本或输入日期值等。不幸的是，大多数试图模仿 HTML 形式的媒体类型格式仍处于草稿版本。
如果您特别看一下 HTML forms，您可能会明白我指的是什么。表单内可能出现的每个元素都经过明确定义，以避免歧义并提高互操作性。这实际上是 REST 的最终目标，让一个客户端能够与大量其他服务进行交互，而无需明确适应每个服务 API。
REST 的美妙之处在于，它不限于单一的表示形式，即 JSON，事实上，几乎有无数种可能的表示格式可以在 REST 环境中交换。 Plain application/json 对于 REST 应用程序 IMO 来说是一种糟糕的媒体类型，因为它不包含任何关于链接和表单的定义，并且不描述可能在请求和响应中传送的某些字段的语义。缺乏语义描述通常会导致 typed resources where a recipient expects that receiving data from i.e. /api/users returns some specific user data, that may differ from host to host. If you skim through IANA's media type registry 你会发现一些你可以用来传输用户相关数据的媒体类型格式，任何支持这些表示格式的客户端都可以与这个 enpoint 交互而无需任何问题。菲尔丁自己声称
A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). (Source)
通过内容类型协商，客户端和服务器将协商支持和理解的表示格式。因此，问题不应该是支持哪一个，而是你想支持多少。您的 API 或客户端能够交换有效载荷的媒体类型越多，与其他参与者互动的可能性就越大。
大多数所谓的 REST API 实际上只是通过 HTTP 公开的 RPC 服务，这些服务可能尊重也可能不尊重和支持某些 HTTP 操作。因此 HTTP 只是一个传输层 whose domain is the transfer of files or data over the Web. Plenty of people still believe that you shouldn't put verbs in URIs when in reality a script or process usually doesn't (and shouldn't) care whether a URI contains a verb or not. The URI itself is just a pointer a client will follow and invoke when it is interested in receiving the payload. We humans are also not that much interested in the URI itself in regards to the content it may return after invoking that URI. The same holds true for arbitrary clients. It is more important what you ship along with that URI. On the Web a link can be annotated with certain text and/or link relation names that set the links content in relation to the current page. It may hint a client that certain content may be invoked before the whole response was parsed as it is quite likely that the client will also want to know about that. preload i.e. is such a link-relation name that hints the client about that. If certain domain-specific terms exist one might use an extension scheme as defined by Web linking or reuse common knowlege or special microformats.
REST 环境中的整个交互类似于 playing a text-based computer game 或遵循应用程序域协议定义的特定流程（即订购和支付产品），可以将其设计为状态机。因此，客户将在整个过程中得到指导。它基本上只是遵循服务器给它的命令，有一些选择来打破这个过程（即在支付前取消订单）。
另一方面，正如您所说，SOAP 是一种基于 XML 的 RPC 协议，它重用 HTTP 的子集来交换请求和响应。当您更改 WSDL 中的某些内容时，很多客户端必须进行调整和重新编译的可能性非常高。 SOAP 甚至定义了自己的安全机制，而不是重用 TLS，因此需要客户端的明确支持。由于状态可能保留在过程中，因此您拥有一对一的通信模型，因此扩展 SOAP 服务并不那么容易。在 REST 环境中，这只是在服务器之前添加一个负载平衡器然后对服务器进行 n 次镜像的问题。由于 stateless constraint
，负载均衡器可以将请求发送到任何服务器
What is the 'mixture' typically referred to as (besides, maybe, a bad API). Is there a word for it? or a concept I can refer to that'll make most developers understand what I'm referring to, without having to say the entire paragraph I did above?
Is it just "JSON SOAP API?", "A Service-based REST API?" - what would you call it?
在 HTTP 之上通信的 API 的通用术语是 Web API 或 HTTP API IMO。 This article also uses this term. It also lists XML-RPC and JSON-RPC besides SOAP. I do agree with Voice though that you'll receive 5 answers on asking 4 people about the right term to use. While it would be convenient to have a respective term available everyone would agree upon, the reality shows that people are not that interested in a clear separation. Just look here at SO on the questions taged with rest. There is nothing wrong with not being "RESTful", though one should avoid the term REST for truly RPC services. Though I think we are already in a situation where the term REST can't be rescued from misusage and .
对于需要外部文档才能使用并且带有自己的自定义非标准化表示格式或仅公开域对象的 CRUD 的内容，我会向其添加 -RPC，因为这更多或更少是它的核心。因此，如果 API 发送 JSON 并且期望的表示是通过 Swagger 或其他一些外部文档记录的 JSON-RPC 可能是最合适的名称 IMO.
总结一下 post，我希望我能阐明 REST 的真正含义，以及您的观察是如何被所有那些不幸的是 RPC 彻头彻尾的实用尝试所缺陷。如果你在他们的实施中改变一些东西，有多少客户会崩溃？除此之外，您不能开箱即用地重用为 API A 实现的客户端与 API B（不同公司或供应商的）进行交互，因此必须适应您的客户或专门为此创建一个新客户 API。这是真正的 RPC，因此应该以某种方式反映在名称中，以提示开发人员未来的期望。不幸的是，正确命名事物的过程，尤其是关于 REST 的过程似乎已经丢失。有一个很好但很小的团体试图传播真正的意义，比如 Voice、Cassio 和其他一些人，尽管这就像在与风车搏斗。这里最好的建议是首先讨论命名约定以及每个参与者对哪个术语的理解，然后就每个人都同意的命名方案达成一致，以避免将来出现混淆。
我对 SOAP 与 REST 的理解：
REST = JSON，简单一致的接口，让您可以 CRUD 访问 'entities'（不一定是单个 DB 行的事物的抽象），更简单的协议，没有正式的强制执行 'contract'（例如，端点 return 的值可以更改，但不应该更改）
SOAP = XML，更复杂的接口，让你可以访问'services'（你可以对实体应用特定的操作，而不是让你直接对实体进行增删改查），正式强制执行，预先规定 'contract'（类似于 WSDL，其中 return 类型是预定义和形式化的）
这是一个大致正确的评估吗？
混合物怎么样？
如果是这样，我怎么称呼 API 是混合物？
例如，如果我们在表面层 看起来 像 REST API（returns JSON，没有 WSDL 或定义了正式的合同 - 但不是让您访问系统管理的 'entities'（用户、产品、评论等），而是让您访问服务和复杂操作的特定权限（/sendUserAnUpdate/1111、/makeCommentTextPurple/3333, /getAllCommentsByUserThisYear/2222) 没有完全覆盖？
'services' 已经在内部存在，团队只需按请求发布对它们的访问，否则看起来像 REST API。
问题：
通常指的 'mixture' 是什么（此外，也许是坏的 API）。有词吗？或者我可以参考的概念将使大多数开发人员理解我所指的内容，而不必说出我在上面所做的整个段落？
仅仅是“JSON SOAP API？”，“基于服务的 REST API？” - 你会怎么称呼它？
谢谢！ 谢谢！
My understanding of SOAP vs REST
...
Is that a broadly correct assessment?
没有
REST 是一种“架构风格”，也就是说架构约束的协调集合。万维网是使用 REST 架构风格构建的应用程序示例。
SOAP is a transport agnostic message protocol specification, based on XML Information Set
If so, what do I call an API that is a mixture?
我认为您不会在这里找到权威术语。通俗地说，您可能会听到广义的术语“web api”来描述不是“RESTful”的 HTTP API。
整个space被semantic diffusion污染了。
如果您看一下所有那些所谓的 REST-API，您的观察可能看起来是正确的，尽管 REST 实际上是完全不同的东西。它描述了一个 architecture or a philosophy whose intent it is to decouple clients from servers, allowing the latter one to evolve in future without breaking clients. It is quite similar to the typical Web page interaction in that a server will teach a client on what it needs and only reacts on client-triggered requests. One has to be pretty careful and pendant when designing REST services as it is too easy to include a coupling that may affect clients when a change is introduced, especially with all the pragmatism around in (commercial) software engineering. Stefan Tilkov gave a great talk on REST back in 2014 that, alongside with Jim Webber or Asbjørn Ulsberg，可以用作介绍 REST 的核心内容的讲座。
REST 的一般前提应该始终是服务器教导客户端他们需要什么以及服务器期望什么，并通过链接向客户端提供选择。如果服务器希望从客户端接收数据，它会发送一个表单式的表示来通知客户端它支持的各个字段，并根据表单中包含的各个元素的 affordance 客户端知道是否select 一个或多个选项，输入一些自由文本或输入日期值等。不幸的是，大多数试图模仿 HTML 形式的媒体类型格式仍处于草稿版本。
如果您特别看一下 HTML forms，您可能会明白我指的是什么。表单内可能出现的每个元素都经过明确定义，以避免歧义并提高互操作性。这实际上是 REST 的最终目标，让一个客户端能够与大量其他服务进行交互，而无需明确适应每个服务 API。
REST 的美妙之处在于，它不限于单一的表示形式，即 JSON，事实上，几乎有无数种可能的表示格式可以在 REST 环境中交换。 Plain application/json 对于 REST 应用程序 IMO 来说是一种糟糕的媒体类型，因为它不包含任何关于链接和表单的定义，并且不描述可能在请求和响应中传送的某些字段的语义。缺乏语义描述通常会导致 typed resources where a recipient expects that receiving data from i.e. /api/users returns some specific user data, that may differ from host to host. If you skim through IANA's media type registry 你会发现一些你可以用来传输用户相关数据的媒体类型格式，任何支持这些表示格式的客户端都可以与这个 enpoint 交互而无需任何问题。菲尔丁自己声称
A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). (Source)
通过内容类型协商，客户端和服务器将协商支持和理解的表示格式。因此，问题不应该是支持哪一个，而是你想支持多少。您的 API 或客户端能够交换有效载荷的媒体类型越多，与其他参与者互动的可能性就越大。
大多数所谓的 REST API 实际上只是通过 HTTP 公开的 RPC 服务，这些服务可能尊重也可能不尊重和支持某些 HTTP 操作。因此 HTTP 只是一个传输层 whose domain is the transfer of files or data over the Web. Plenty of people still believe that you shouldn't put verbs in URIs when in reality a script or process usually doesn't (and shouldn't) care whether a URI contains a verb or not. The URI itself is just a pointer a client will follow and invoke when it is interested in receiving the payload. We humans are also not that much interested in the URI itself in regards to the content it may return after invoking that URI. The same holds true for arbitrary clients. It is more important what you ship along with that URI. On the Web a link can be annotated with certain text and/or link relation names that set the links content in relation to the current page. It may hint a client that certain content may be invoked before the whole response was parsed as it is quite likely that the client will also want to know about that. preload i.e. is such a link-relation name that hints the client about that. If certain domain-specific terms exist one might use an extension scheme as defined by Web linking or reuse common knowlege or special microformats.
REST 环境中的整个交互类似于 playing a text-based computer game 或遵循应用程序域协议定义的特定流程（即订购和支付产品），可以将其设计为状态机。因此，客户将在整个过程中得到指导。它基本上只是遵循服务器给它的命令，有一些选择来打破这个过程（即在支付前取消订单）。
另一方面，正如您所说，SOAP 是一种基于 XML 的 RPC 协议，它重用 HTTP 的子集来交换请求和响应。当您更改 WSDL 中的某些内容时，很多客户端必须进行调整和重新编译的可能性非常高。 SOAP 甚至定义了自己的安全机制，而不是重用 TLS，因此需要客户端的明确支持。由于状态可能保留在过程中，因此您拥有一对一的通信模型，因此扩展 SOAP 服务并不那么容易。在 REST 环境中，这只是在服务器之前添加一个负载平衡器然后对服务器进行 n 次镜像的问题。由于 stateless constraint
，负载均衡器可以将请求发送到任何服务器What is the 'mixture' typically referred to as (besides, maybe, a bad API). Is there a word for it? or a concept I can refer to that'll make most developers understand what I'm referring to, without having to say the entire paragraph I did above?
Is it just "JSON SOAP API?", "A Service-based REST API?" - what would you call it?
在 HTTP 之上通信的 API 的通用术语是 Web API 或 HTTP API IMO。 This article also uses this term. It also lists XML-RPC and JSON-RPC besides SOAP. I do agree with Voice though that you'll receive 5 answers on asking 4 people about the right term to use. While it would be convenient to have a respective term available everyone would agree upon, the reality shows that people are not that interested in a clear separation. Just look here at SO on the questions taged with rest. There is nothing wrong with not being "RESTful", though one should avoid the term REST for truly RPC services. Though I think we are already in a situation where the term REST can't be rescued from misusage and
对于需要外部文档才能使用并且带有自己的自定义非标准化表示格式或仅公开域对象的 CRUD 的内容，我会向其添加 -RPC，因为这更多或更少是它的核心。因此，如果 API 发送 JSON 并且期望的表示是通过 Swagger 或其他一些外部文档记录的 JSON-RPC 可能是最合适的名称 IMO.
总结一下 post，我希望我能阐明 REST 的真正含义，以及您的观察是如何被所有那些不幸的是 RPC 彻头彻尾的实用尝试所缺陷。如果你在他们的实施中改变一些东西，有多少客户会崩溃？除此之外，您不能开箱即用地重用为 API A 实现的客户端与 API B（不同公司或供应商的）进行交互，因此必须适应您的客户或专门为此创建一个新客户 API。这是真正的 RPC，因此应该以某种方式反映在名称中，以提示开发人员未来的期望。不幸的是，正确命名事物的过程，尤其是关于 REST 的过程似乎已经丢失。有一个很好但很小的团体试图传播真正的意义，比如 Voice、Cassio 和其他一些人，尽管这就像在与风车搏斗。这里最好的建议是首先讨论命名约定以及每个参与者对哪个术语的理解，然后就每个人都同意的命名方案达成一致，以避免将来出现混淆。