V2 和 WSI Magento SOAP 接口有什么作用?
Magento 有一个可通过 SOAP 和 RPC 访问的“Webservices API”。
这个术语在这里变得很奇怪,因为 SOAP(或 RPC)API 本身只公开 8 个方法。要访问 Magento API 中的方法,您可以调用 SOAP api 方法 call
,然后传入一个字符串来指示您真正想要调用的方法(类似于 catalog_product.info
)
多年来Magento 团队引入了两个额外的 API 后端:SOAP V2 和 SOAP WSI。引入这些后端“是为了提高与 .NET 和 Java 的兼容性”,
这到底意味着什么?从代码的角度来看,这些 API 更改了公开的 WSDL,并且当使用 PHP 的 SOAP 客户端时,整个 call
事情就会消失。您在客户端上调用实际方法本身就消失了,
$client->call($session, 'catalog_product.info',...);
vs.
$client->catalogProductInfo($sessionId, ...
我一直不清楚这如何提高 .NET 或 Java 兼容性(因为我不熟悉这些工具链)。
这只是代码生成方便/文化的问题,还是 .NET 和 Java 用户实际上不可能使用原始的 SOAP API?
Magento has a "Webservices API" that's accesible via SOAP and RPC.
The terminology gets a screwy here, as the SOAP (or RPC) API itself only exposes 8 methods. To access a method in the Magento API you call the SOAP api method call
, and then pass in a string that indicates the method you really want to call, (something like catalog_product.info
)
Over the years the Magento team introduced two additional API backends, SOAP V2, and SOAP WSI. These backends were introduced "To increase compatibility with .NET and Java"
What does this mean, exactly? From a code point of view these APIs change the WSDL that's exposed, and when using PHP's SOAP client the whole call
thing goes away. You're calling actual methods on the client itself goes away
$client->call($session, 'catalog_product.info',...);
vs.
$client->catalogProductInfo($sessionId, ...
It's never been clear to me how this improves .NET or Java compatibility (because I'm not familiar with those tool-chains).
Is this just a code generation convenience/culture thing, or is it literally impossible for .NET and Java users to use the original SOAP API?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
总体来说有什么改进?
WSDL 描述的 SOAP 服务的构建块大致如下:
契约:由 wsdl:portType、wsdl:message 和 wsdl:type 指定,描述操作以及这些操作所操作的消息和类型。所以这说明:该服务可以做什么?
绑定:wsdl:binding 将 wsdl:portType 绑定到具体的传输、文档样式、策略等。这告诉我们:如何与服务对话?
地址:wsdl:service 部分将 wsdl:binding 链接到具体的服务端点地址。这回答:服务在哪里?
上述几点或多或少是 Windows Communication Foundation (WCF) 的 ABC 原则。
因此,magento 的第一个 RPC 方法只是对 SOAP 协议的滥用。通过少数入口函数的关键孔的每个请求都有另一个包装的 RPC 协议作为消息负载。所以 SOAP 只是用作消息传输,就像 SOAP 使用的那样。 HTTP-POST。为了保持合约有效,它必须非常复杂(大量可能的消息)或非常通用(只是一个字符串)。如果每个方法/操作都有自己的声明,那么契约就会变得更加容易。这就是 V2 API 的作用。
但为什么这对于 Java 或 C# 等静态类型语言来说也是一个很大的改进呢?
正如 macki 提到的,这些语言有工具(代理生成器等)和框架(如 WCF 或 JAX-WS)。它们根据上面提到的消息类型的合同数据传输对象(DTO)和方法调用的代理来生成(它们做了更多的事情,但这在这里并不重要)。正如您在 Magento Wiki on C# magentosoap v2 api 中看到的实例化filters-object并使用salesOrderList代理方法。契约的很大一部分是基于方法及其参数的静态类型。如果您要使用 V1 锁孔方法,您必须在更任意的数据结构(如字符串、字符串数组或字符串字典)中自行构建消息以满足合约。
因此,当然可以使用静态类型语言中的旧 API,但感觉不太对。每个消息类型都有一个类型和操作代理的静态类型签名要好得多。除此之外,V2 还提供更好的 SOAP 服务,无论您使用哪种语言调用它们。
What was the improvement in general?
The building blocks of a SOAP service described by WSDL are roughly:
Contract: Specified by wsdl:portType, wsdl:message and wsdl:type, that describes operations as well as the messages and types these operate on. So this tells: What can the service do?
Binding: A wsdl:binding binds a wsdl:portType to a concrete transport, a document style, policies, etc. This tells: How to talk to the service?
Address: wsdl:service section links a wsdl:binding to an concrete service endpoint address. This answers: Where is the service?
The above mentioned points are more or less the ABC-tenet of the Windows Communication Foundation (WCF).
So the first RPC-approach of magento was simply an abuse of the SOAP protocol. Every request going through the key-hole of the few entry-functions has another, wrapped RPC protocol as message payload. So SOAP was just used as an message transport, just like SOAP uses eg. HTTP-POST. To keep the contract valid, it has to be either very complex (an enormous amount of possible messages) or very generic (simply a string). The contract becomes much easier if every method/operation has it's own declaration. That is what the V2 API does.
But why is this also a big improvement for static typed languages like Java or C#?
Like macki mentioned, there is tooling (proxy generators, etc) and frameworks (like WCF or JAX-WS) for these languages. They generate depending on the above mentioned contract data transfer objects (DTO)s for the message-types and proxies for the method invocation (they do much more but that's not important here). As you see in the Magento Wiki on C# magento soap v2 api an filters-object is instantiated and the salesOrderList proxy method. A good part of the contract is based on static typing of the method and its parameter. If you would use the V1 keyhole-methods you had to build the messages to satisfy the contract by yourself in an more arbitrary data structure like a string, array of strings or dictionary of strings.
So of course it is possible to use the old API from static typed languages it doesn't feel right. It is much better to have on type per message-type and a statically typed signature of operation proxies. Beside that V2 are also better SOAP service regardless the language you call them with.
据我所知,至少在 .NET 中,您必须手动完成所有操作(因为没有可用方法的 WSDL 规范),而在 V2 中,您可以使用各种“向导”和“WSDL 导入器”来创建代理具有正确数据类型和名称的类。使编码变得更加容易。原始方法还存在复杂数据类型的问题——它们很难直接使用。
From what I know at least in .NET with the original ones you have to do everything manually (as there is no WSDL specification of available methods) and with the V2 you can use various "wizards" and "WSDL importers" that will create proxy classes with correct data types and names. Makes it much easier to code. Also there is a problem with complex data types with the original methods - they are hard to work with directly.
有 105 个 Magento SOAP v2 函数 API,您应该了解它们的使用和应用。
首先转到 Magento SOAP 了解如何创建 SOAP 客户端和登录。查看 SOAP API v2 的相当简短的描述。然后从 PHP CLI(通过命令行)或 PHP CGI(通过 Web 浏览器)各自的脚本引擎运行以下代码。
将 SOAP v2 API 函数列表剪切并粘贴到文本文件中并保存。您会发现 API 列表非常宝贵,因此您需要随身携带。
There are 105 Magento SOAP v2 function APIs, that you should be aware of their use and application.
First go to Magento SOAP on how to create a SOAP client and login. The check out the rather brief description of the SOAP API v2. Then run the following code from your PHP CLI (via command line) or PHP CGI (via Web browser) respective script engine.
Cut and paste the SOAP v2 API function list to a text file and save it. You'll find the API list will be invaluable, so you will want to keep handy.