- XML-在SOAP （总是）和REST请求（很少使用）中使用；
- JSON-在REST请求中使用。
今天，我将向您介绍XML。
XML，从英语翻译Ë X tensible中号arkup大号anguage是一种可扩展标记语言。用于存储和传输数据。因此，您不仅可以在API中看到它，还可以在代码中看到它。
万维网联盟（W3C）推荐使用这种格式，因此通常用于通过API传输数据。在SOAP API中，通常这是输入和输出数据的唯一可能格式！
另请参阅：
什么是API - API的一般介绍
SOAP和REST简介：它是什么以及可以吃什么-有关SOAP和REST之间的区别的视频。
因此，让我们弄清楚它的外观，如何阅读以及如何破解它！是的，是的，但是没有它呢？毕竟，有必要找出系统将如何响应所发送数据的曲线格式。
内容
XML如何工作
让我们以Dadata的全名提示文档为例：
<req>
<query> </query>
<count>7</count>
</req>让我们弄清楚该条目的含义。
标签
在XML中，每个元素都必须包装在标签中。标签是一些用尖括号包裹的文本：
<tag>尖括号内的文本是标签名称。
总有两个标签：
- 开瓶器-尖括号内的文本
<tag> - 关闭-相同的文本（这很重要！），但是添加了符号“ /”
</tag>
哦，好的，被抓住了！不总是。也有空元素，它们有一个标签，同时打开和关闭。但是稍后再说吧！
在标签的帮助下，我们向系统显示“元素从此开始，在此结束”。就像路标一样：
-在城市的入口处，它的名字是这样写的：莫斯科
-在出口处是相同的名字，但是却划掉了：
*我很久以前在Yandex上的一篇文章中提到过一个路标的例子，只有我不记得这个链接。和一个很好的例子！
根元素
任何XML文档都具有根元素。这是文档开始和结束的标签。对于REST API，文档是系统发送的请求。还是她得到的答案。
要指定此请求，我们需要一个根元素。在工具提示中，根元素是“ req”。
可以将其称为：
<main><sugg>是的，随便 它显示了我们请求的开始和结束，仅此而已。但是内部已经有文档的主体-请求本身。我们传递给外部系统的那些参数。当然，它们也将在标签中，但在常规标签中，而不是在根标签中。
物品价值
元素的值存储在开始标记和结束标记之间。它可以是数字，字符串，甚至是嵌套标签！
在这里，我们有“查询”标签。它表示我们发送到工具提示的请求。
内部-请求的值。
就像我们将“ Victor Ivan”行插入GUI（图形用户界面）一样：
用户不需要额外的约束，他需要一个漂亮的表格。但是系统必须以某种方式传达“用户准确输入了此信息”。如何向她显示传递的值的开始和结束位置？这就是标签的用途。
系统看到“查询”标签，并了解其中是“应返回提示的字符串”。
参数计数= 7指示在响应中返回多少提示。如果您在Dadata的演示表单上戳技巧，则会向我们返回7条提示。这是因为值计数= 7被缝入其中。但是，如果您参考该方法的文档，则可以从1到20中选择计数。
通过f12的“网络”选项卡打开开发人员控制台，然后查看将什么请求发送到服务器。将有一个计数= 7。
另请参阅：
测试人员需要了解的开发人员面板-了解有关如何使用控制台的更多信息。
注意：
- Victor Ivan-琴弦
- 7-数字
但是两个值都没有引号。在XML中，我们不需要将字符串值括在引号中（但在JSON中，我们必须这样做）。
元素属性
元素可以具有一个或多个属性。我们在标签名称后面的空格中以空格隔开后将它们指示在可撕标签内
_ = « »例如：
<query attr1=“value 1”> </query>
<query attr1=“value 1” attr2=“value 2”> </query>
为什么需要这个？从属性中，接收API请求的系统完全了解它已收到的内容。
例如，我们在系统上进行搜索，以查找名称为Oleg的客户。我们发送一个简单的请求：
<query></query>作为回报，我们将获得一整包欧列格！具有不同的出生日期，电话号码和其他数据。假设其中一个搜索结果如下所示：
<party type="PHYSICAL" sourceSystem="AL" rawId="2">
<field name=“name"> </field>
<field name="birthdate">02.01.1980</field>
<attribute type="PHONE" rawId="AL.2.PH.1">
<field name="type">MOBILE</field>
<field name="number">+7 916 1234567</field>
</attribute>
</party>让我们看看这个条目。我们有主要聚会。
它具有3个属性：
- type = «PHYSICAL» — . , : , , . , . ! , , — ,
- sourceSystem = «AL» — . , , .
- rawId = «2» — . , , . , ? sourceSystem + rawId!
派对 里有场上的元素。字段
元素具有名称属性。该属性值为字段名称：名称，出生日期，类型或电话号码。这就是我们了解特定字段下隐藏的内容的方式。 当您有盒装产品和10个以上的客户时，从支持的角度来看这很方便。每个客户都有自己的一组字段：一个人在系统中有一个INN，一个人没有，一个人对出生日期很重要，另一个人没有生日，等等。 但是，尽管模型有所不同，但所有客户都将拥有一个XSD模式（描述请求和响应）： -有一个聚会元素； -它具有领域要素；
-每个字段元素都有一个名称属性，用于存储字段名称。
但是，字段的特定名称不再可以在XSD中描述。他们已经“看着传统知识”。当然，当只有一个客户或者您是为自己或“通常为每个人”制作软件时，使用命名字段（即“说”标签）会更方便。这种方法的优点是：
-读取XSD时，立即显示真实字段。 TK可能已过时，并且代码将是最新的。
-该请求很容易在SOAP Ui中手动拉出-它会立即创建所有必要的字段，您只需要填写值即可。这对于测试人员来说很方便+客户有时会像这样进行测试，他也很好。
通常，任何方法都有权存在。有必要查看该项目，这对您来说将更加方便。在我的示例中，我使用的元素没有说话的名称-所有这些都是领域。但是通过属性，您已经可以了解它的含义。
除字段元素外，party还具有属性元素。不要混淆xml符号和业务阅读：
- 从业务角度来看，这是个人的属性，因此是element- attribute的名称。
- 从xml的角度来看，它是一个元素（不是属性！），它只是简单地命名为attribute。XML不在乎（几乎）如何命名元素，所以没关系。
attribute 元素具有以下属性：
- type =“ PHONE” -属性类型。毕竟，它们可以不同：电话，地址，电子邮件...
- rawId =“ AL.2.PH.1” -源系统中的标识符。需要更新。毕竟，一个客户可以拥有几部电话，一个人如何才能知道没有ID的电话正在更新？
原来是XML。并简化。在存储个人的实际系统中，会有更多的数据：个人本人的大约20个字段，几个地址，电话号码，电子邮件地址……
但是，如果您知道什么地方，即使读取巨大的XML也不会很困难。如果已格式化，则嵌套元素将向右移动，其余元素处于同一级别。没有格式将很难...
而且一切都如此简单-我们将元素括在标签中。标签内是元素的名称。如果名称后面有东西，则用空格隔开：这是元素的属性。
XML序言
有时，在XML文档的顶部，您会看到类似的内容：
<?xml version="1.0" encoding="UTF-8"?>此行称为XML序言。它显示了文档中使用的XML版本以及编码。序言是可选的（如果没有的话）-可以。但是，如果是，那么它必须是XML文档的第一行。
UTF-8是XML文档的默认编码。
XSD模式
XSD（X ML小号CHEMA d efinition）是你的XML描述。它看起来如何，应该是什么？这是用机器语言编写的TK-毕竟，我们编写了模式...也是XML格式！结果是描述另一个XML的XML。
诀窍是可以将根据方案进行的检查委派给机器。而且，开发人员甚至不必安排所有检查。只需说“这里是图表，检查一下”即可。
如果我们创建一个SOAP方法，那么我们在模式中指出：
- 请求中将包含哪些字段；
- 响应中将包含哪些字段；
- 每个字段具有哪些数据类型；
- 哪些是必填字段，哪些不是必填字段；
- 该字段是否具有默认值，它是什么？
- 字段是否有长度限制？
- 该字段是否还有其他参数？
- ;
- ...
现在，当收到请求时，将首先根据方案检查其正确性。如果请求正确，我们将启动该方法并制定业务逻辑。而且它可能很复杂且占用大量资源！例如，从数百万美元的数据库中进行抽样。还是对不同的数据库表进行一打检查...
那么，如果查询显然是“不好的”，为什么还要运行一个复杂的过程呢？并在5分钟后（而不是立即）给出错误？模式验证有助于快速过滤掉明显无效的请求，而不会导致系统过载。
而且，某些客户端程序为发送请求提供了类似的保护。例如，SOAP Ui可以检查您对格式正确的xml的请求，如果您搞砸了，它将不会将其发送到服务器。节省时间，做得好！
对于SOAP API的简单用户而言，该模式可帮助您了解如何编写请求。什么是“简单用户”？
- 使用您的API的系统的开发人员-他需要在代码中写出从他的系统发送到您的系统的确切信息。
- 需要检查此API的测试人员-他需要了解请求的形成方式。
是的，是的，理想情况下，我们有详细的传统知识，所有内容都得到了很好的描述。但是，可惜啊，并非总是如此。有时，传统知识根本不存在，而有时则已过时。但是，该架构不会过时，因为在更新代码时会对其进行更新。它只是有助于了解请求的外观。
总之，开发SOAP API时如何使用模式：
- 我们的开发人员为API请求编写了XSD架构：您需要传递具有诸如此类的子元素，具有此类数据类型的元素的此类元素。这些是必需的，不是必需的。
- 与我们集成的客户系统的开发人员阅读此图并根据该图建立其请求。
- 客户系统向我们发送请求。
- 我们的系统会检查对XSD的请求-如果出了问题，那就太麻烦了。
- 如果XSD请求通过了验证，请打开业务逻辑！
现在，让我们看看电路的外观！以Users中的doRegister方法为例。要发送请求，我们必须传递电子邮件，名称和密码。有很多写对与错查询的方法：
| 正确的要求 | 无效请求 |
|---|---|
|
没有必填名称字段 |
|
标记名称中的错字（邮件而不是电子邮件） |
| ... | ... |
让我们尝试为其编写图表。该请求必须包含类型为“字符串”（字符串）的3个元素（电子邮件，名称，密码）。我们写：
<xs:element name="doRegister ">
<xs:complexType>
<xs:sequence>
<xs:element name="email" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="password" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>在该服务的WSDl中，它的编写更加简单：
<message name="doRegisterRequest">
<part name="email" type="xsd:string"/>
<part name="name" type="xsd:string"/>
<part name="password" type="xsd:string"/>
</message>当然，一个模式不仅可以包含内联元素。这些可以是数字，日期，布尔值，甚至可以是它们自己的某些类型：
<xsd:complexType name="Test">
<xsd:sequence>
<xsd:element name="value" type="xsd:string"/>
<xsd:element name="include" type="xsd:boolean" minOccurs="0" default="true"/>
<xsd:element name="count" type="xsd:int" minOccurs="0" length="20"/>
<xsd:element name="user" type="USER" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>您还可以在架构中引用另一个架构，这使编写代码更加容易-您可以将架构重用于不同的任务。
另请参阅： XSD-
智能XML -habr的有用文章
XSD Schema定义语言-有一些带有值的方便表，您可以使用
XSD Schema Description Language（XML-Schema）
教程中的XML架构示例
官方网站w3.org
实践：编写您的请求
好的，现在我们知道了如何“读取” XML格式的API方法请求。但是如何根据传统知识来拟定呢？我们试试吧。我们看一下文档。这就是为什么我要举Dadata的例子-这是很棒的文档！
如果我只想返回以“ An”开头的女性全名怎么办？让我们以原始示例为例：
<req>
<query> </query>
<count>7</count>
</req>首先，我们更改请求本身。现在不再是“ Victor Ivan”，而是“ An”：
<req>
<query></query>
<count>7</count>
</req>接下来，我们看一下传统知识。如何只退还女性小费？有一个特殊的参数-性别。参数名称是标签的名称。我们已经将地板放在里面了。文档中的英语“ Female”也是FEMALE。收到的总数：
<req>
<query></query>
<count>7</count>
<gender>FEMALE</gender>
</req>您可以删除不必要的内容。如果我们不在乎提示的数量，我们将丢弃count参数。毕竟，根据文档，它是可选的。收到请求：
<req>
<query></query>
<gender>FEMALE</gender>
</req>就这样！我们以一个示例为基础，更改一个值，添加一个参数，删除一个。没那么难。特别是有详细的说明和示例时）））
自己尝试！在“用户”中
为MagicSearch方法编写请求。我们希望通过完全巧合的方式找到所有伊万诺夫人，这些紧急任务挂在上面。
格式正确的XML
由开发人员决定哪种XML正确，哪些不正确。但是有一些不可违反的一般规则。XML必须格式正确，即语法正确。
要检查XML的语法，可以使用任何XML验证程序（和Google）。我推荐w3schools网站。验证器本身+典型错误的描述以及示例。
在完成的验证器中，您只需插入XML（例如，对服务器的请求），然后查看它是否一切正常。但是您可以自己检查。仔细阅读语法规则，看看您的查询是否遵循它们。
格式正确的XML规则：
- 有一个根元素。
- 每个元素都有一个结束标记。
- 标签区分大小写！
- 观察到正确的元素嵌套。
- 属性用引号引起来。
让我们遍历每条规则，并讨论如何在测试中应用它们。也就是说，如何通过对照格式正确的xml检查查询来正确地“中断”查询。为什么需要这个？查看来自系统的反馈。您能从错误文本中确切地了解到您的错误之处吗？
另请参阅：
错误消息也是文档，请对其进行测试！-为什么测试错误消息
1.有一个根元素
您不能仅仅将2个XML并排放置，并假设“系统将自己确定这是两个请求，而不是一个”。不会理解。因为你不应该。
而且，如果您连续有多个标记而没有一个公共父标记，则这是错误的xml，格式不正确。始终应该有一个根元素：
| 没有 | 是 |
|---|---|
有元素“ test”和“ dev”，但它们彼此相邻放置，但没有根，所有内容都位于其中。看起来更像2个XML文档 |
这已经有一个凭证元素，这是根源 |
我们正在做什么以测试这种情况？是的，我们从请求中删除了根标签！
2.每个元素都有一个结束标记
这里的一切都很简单-如果标签已在某处打开，则必须在某处关闭。想休息吗？删除任何元素的结束标记。
但在这里值得注意的是，可以有一个标签。如果该元素为空，则可以通过在结尾处将其关闭来获得一个标签：
<name/>这与在其中传递空值相同
<name></name>同样，服务器可以向我们返回一个空标签值。您可以尝试使用FullUpdateUser方法向用户发送空字段。并且在请求中，这是允许的（我向name1字段发送了empty ），并且在SOAP Ui响应中，它准确地向我们呈现了空白字段。
总计-如果有一个开始标签，那么必须有一个结束标签。否则它将是一个标签，最后是一个斜杠。
为了进行测试，请删除请求中的所有结束标记。
| 没有 | 是 |
|---|---|
|
|
|
|
3.标签区分大小写
当他们写开头一时，我们也写了结尾一。类似！而不是您想要的方式。
但是，为了进行测试，我们更改了零件之一的寄存器。这样的XML将无效
| 没有 | 是 |
|---|---|
|
|
4.正确的元素嵌套
元素可以一个接
一个地放置一个元素可以嵌套在另一个
元素中，但是元素不能相互重叠！
| 没有 | 是 |
|---|---|
|
|
|
|
5.属性用引号引起来
即使您认为该属性是数字，也将其引用起来：
<query attr1=“123”> </query>
<query attr1=“” attr2=“123” > </query>出于测试目的，我们尝试不带引号通过它：
<query attr1=123> </query>总
XML（E X tensible中号arkup大号anguage）用于存储和传输数据。
— API-. SOAP-, . SOAP XML. REST, — XML, JSON.
— XML . , . XML - , , - .
XML open-source folks. , JacksonJsonProvider, «» — , (featuresToEnable), , (featuresToDisable).
XML格式遵循标准。语法上不正确的请求甚至不会发送到服务器，客户端会削减该请求。格式正确的业务逻辑。
格式正确的XML规则：
- 有一个根元素。
- 每个元素都有一个结束标记。
- 标签区分大小写！
- 观察到正确的元素嵌套。
- 属性用引号引起来。
如果您是一名测试人员，那么在测试XML查询时，请务必尝试打破所有规则！是的，系统应该能够处理此类错误并返回适当的错误消息。但是她并不总是这样做。
而且，如果系统是公共的，并且对错误的请求返回空响应，那就很糟糕。因为另一个系统的开发人员将在请求中修复该问题，而如果回答是空的，他甚至将不了解确切的位置。并且它会缠扰支持：“我怎么了？”，逐段地以源代码的屏幕截图的形式抛出信息。你需要它吗？没有？然后确保系统给您清晰的错误消息！
另请参阅：
什么是XML XML
教程
学习XML。 Eric Ray（XML书）
关于XML和XLST的说明
PS-有关更多有用的文章，请查看我的博客下的“ useful”标签。有用的视频在我的YouTube频道上