• 构造请求

  构造请求建议在支持携带正文的请求中使用 JSON 格式的数据，而不是使用表单或其他形式的数据。这样的好处在于 JSON 所支持的数据类型更为丰富，在各个语言上也有良好的支持。此外，如果请求正文中包含 Unicode 字符，不建议对其进行转义，而是以明文传输。这样的好处在于减少开销、可读性好，同时也避免了数据在多端传输时，可能产生的一些编码问题。... 全文》

  架构 5年前 | touch

• 关于 REST

  关于 RESTREST（Representational State Transfer）是一种轻量级的 Web Service 架构风格，可以翻译成“表属性状态转移”，实现和操作明显比 SOAP 和 XML-RPC 更为简洁，可以完全通过 HTTP 协议实现，还可以利用缓存来提高响应速度，因此在性能、效率和易用性上都优于 SOAP 协议。REST 架构遵循了... 全文》

  架构 5年前 | touch

• REST Server

  REST ServerREST Server 就是提供 REST API 接口的服务端。REST API 基于最简单的 HTTP 协议，在各个编程语言中都提供了良好的支持。在各个基础服务的内部文档中，会提供一个该服务的基地址（BaseURL）。如果基础服务提供了数据隔离的生产环境与开发环境，基地址可能会有所不同。... 全文》

  架构 5年前 | touch

• REST Client

  REST ClientREST Client 就是调用 REST API 的客户端，可以使调用方式有多种：curl、浏览器、编程语言 HTTP 请求访问实现等。调用 REST API，本质就是发送 HTTP 请求；而谓词所操作的对象，在 REST 中，被称之为资源，也就是 URL，而这些也都是标准的 HTTP 协议的内容。大多数形况下，各服务的 REST A... 全文》

  架构 5年前 | touch

• 响应结果

  响应结果如无特殊说明，文档中给出的响应结果均为 JSON 格式，并遵循 HTTP 状态码语义。通常情况下，响应结果将以 2xx（一般为 200）的 HTTP 状态码返回，形如：{        "errcode": 0,   ... 全文》

  架构 5年前 | touch

• 异常处理

  异常处理请先阅读本文档下有关响应结果的章节。如果接口调用失败，将会在 HTTP 状态码中得到体现，通常可分为两种类型：当 HTTP 状态码为 4xx（请求错误）时，这些状态代码表示请求可能出错，妨碍了服务器的处理，此时应检查客户端配置和代码。当 HTTP 状态码为 5xx（服务器错误）时，这些状态代码表示服务器在尝试处理请求时发生内部错误，此时应通知运维人员... 全文》

  架构 5年前 | touch

• 异常状态码一览表

  异常状态码一览表请先阅读本文档下有关异常处理的章节。以下的异常状态码是各个基础服务通用的，各个基础服务可根据业务需要自行扩展，但禁止覆写通用异常状态码，以免引起歧义。需要注意的是，errmsg 字段的值仅为 errcode 字段的值对照的错误信息，供业务方判断异常状态。但业务方在业务逻辑上不应该依赖 errmsg 字段的值。errcodeerrmsgdesc... 全文》

  架构 5年前 | touch

• 名词解释

  名词解释在各个基础服务的内部文档中，可能出现以下具有特定含义的名词：Path：REST API 的请求路径，需拼接在基地址结尾处。Parameters：REST API 的请求参数，由若干个键值对组成，键与值之间用 = 连接，多个键值对之间用 & 连接，以 ? 拼接在 Path 结尾处（即查询字符串）。并非所有请求参数都是必须的，可选参数将会在文档中... 全文》

  架构 5年前 | touch

• 请求签名校验

  请求签名校验如果基础服务使用了基于请求签名校验的接口安全校验规则，则在构造 HTTP 请求时，需要携带本次请求的签名信息。请求签名不正确、或短时间内重复使用的请求签名，将被认为是非法请求。具体做法分为 无 AppKey 和 有 AppKey 的两种，均需要在请求的查询字符串中携带一个键为 signature 的参数。下面将分情况给出该参数值的计算规则。对于无... 全文》

  架构 5年前 | touch