RESTful JSON Web Service 的概念

阅读本主题以了解 RESTful Web Service 背后的概念。

RESTful Web Service

“代表性状态转移”（或 REST）是一种用于与服务器中存储的资源进行交互的设计模式。每个资源都具有一个身份和一种数据类型并支持一组操作。

RESTful 设计模式通常与因特网语言 HTTP 结合使用。在此上下文中，资源的身份是其 URI，数据类型是其媒体类型，而操作包含标准 HTTP 方法（GET、PUT、POST 和 DELETE）。

该服务样式与请求/响应样式 Web Service 不同：

请求/响应服务开始与应用程序的交互，然而 RESTful 服务通常与数据（称为“资源”）进行交互。
请求/响应服务涉及应用程序定义的“操作”，但是 RESTful 服务与应用程序特定概念无关。
请求/响应服务对于每个消息使用不同的数据格式，但是 RESTful 服务通常在不同 HTTP 方法间共享一种数据格式。

以下四种主要 HTTP 方法定义通常由 RESTful 服务执行的四种操作。 HTTP POST 方法用于创建资源，GET 用于查询资源，PUT 用于更改资源，而 DELETE 用于销毁资源。最常见的 RESTful 体系结构包含在这四种操作中使用的共享数据模型。此数据模型定义 POST 方法（创建）的输入、GET 方法（查询）的输出以及 PUT 方法（替换）的输入。这种简单的设计模式在 RESTful 社区内很常见，但是它不是唯一的 RESTful 设计模式。 HTTP 状态码用于指示操作的成功或失败。某些 RESTful API 是使用其他方式来设计的。

RESTful Web Service 有时还会支持称为“HEAD”的第五种 HTTP 方法。此方法等同于 GET，不同之处是它只返回 HTTP 头，而不返回主体数据。它有时用于测试某个资源是否存在。并非所有 RESTful API 都支持使用 HEAD 方法。

传统 CICS ® 应用程序不太可能与 RESTful 体系结构模式匹配。典型的 CICS 应用程序实现了多个操作，每个操作都将具有用于输入和输出格式的数据模型。这些现有操作不太可能直接映射到这四种 HTTP 方法。因此， RESTful 体系结构模式主要针对 CICS 中的新应用程序。要将现有 CICS 应用程序公开为 RESTful 服务，您可能需要使用符合 RESTful 原则的新接口对其进行打包。

URI

RESTful 服务的身份通过其 URI 来指示。一个 URI 可以含有几个组成部分，包括主机名、端口号、路径和可选查询字符串。域名和端口号一起以 CICS 中的 TCPIPSERVICE 资源为目标。有关更多信息，请参阅 TCPIPSERVICE 资源。 URI 路径是限定符，并且可能足以唯一标识服务。然而，许多 RESTful Web Service 都再使用一个查询字符串来确定准确的资源。让我们来看以下示例：

http://www.example.org:10000/JSONServices/AccountService
https://www.example.org:10000/JSONServices?Service=Account

在第一个示例中，URI 路径为 JSONServices/AccountService。在第二个示例中，路径为 JSONServices 并且存在另外一个查询字符串 Service=Account。对于 JSON，这两种样式的 URI 都视为可接受。这是与 SOAP 相比的一个重要差别。对于 SOAP，首选第一种样式的 URI。

可以使用 z/OS® Connect Enterprise Edition将 CICS JSON 服务转换为 RESTful 服务。图形用户界面用于将 URI 片段和 HTTP 头映射到现有副本的字段中，不同程序可能充当每个 HTTP 方法的目标。与 CICS 中的其他 JSON 技术相比，从现有应用程序资产构造 RESTful 服务是 z/OS Connect 的主要优势之一。

CICS 还有一种较旧的技术，用于实现有限形式的 RESTful 服务。 URIMAP 资源可用于标识处理入站消息时要使用的相应 WEBSERVICE 和 PIPELINE。 URIMAP 可以将 URI 映射到特定的 PIPELINE 或 WEBSERVICE ，可能在该映射中包含 URI 的查询字符串

CICS 使用 URIMAP 资源来标识处理入站消息时要使用的相应 WEBSERVICE 和 PIPELINE。 URIMAP 支持将查询字符串用作 path 属性的一部分。因此，URIMAP 适合用于这两种类型的 URI。