## 使用约定

#### 数据适配约定

请记住`natty-fetch`在数据结构上的约定，当一个项目的服务端数据结构不一致的时候，比如需要对接多个系统，这里的约定就是将各种数据结构统一后的焦点。

`natty-fetch`内部接受的数据结构约定如下：

```js
{
    "success": true,
    "content": {},
    "error": {}
}
```

说明：

* 以`success`键值表示返回的数据是否有错误，以布尔值表示。
  - 当值为`true`时，返回的数据中必须包含`content`对象。
  - 当值为`false`时，返回的数据中必须包含`error`对象。
* 以`content`键值表示数据正确时的数据内容。格式**必须**是一个对象。
* 以`error`键值表示数据有错误时的错误信息，格式**必须**是一个对象。

在`natty-fetch`内部，严格按照上面约定的结构接收和处理数据。项目中可以通过适配函数[`fit`](options.md#fit)将数据结构方便地转换成约定的格式。


#### 接口的层级关系约定(推荐但不强制)

接口的层级关系约定，是指一个数据接口在业务场景下被调用时，应该有清晰的上下层级关系，可以一眼看出这个接口属于哪个系统的哪个模块。

> 💊 在大型的、业务复杂的、人手繁杂的项目代码中，清晰的层级关系(不限于数据接口)，即便是蛛丝马迹，也有助于呈现系统脉络，有助于提高沟通效率，有助于降低维护成本。

##### 实现方式

`natty-fetch`通过两个方式，为实现清晰的接口层级关系提供了极简的方案。

* 通过提供接口上下文，将不同系统或模块的接口明确划分。
* 允许在定义接口的时候，同时指定接口所属的，任意层级的名称空间。同一个上下文下的接口，依然可以划分出多个模块或组。

> 💊 把`natty-fetch`的上下文对象用于划分不同的系统，还是用于划分不同的模块，可以根据配置是否一样来决定。如果两个系统的共享配置一样，完全可以使用同一个上下文。如果两个模块的共享配置不一样，也可以启动两个上下文。项目中需要抛开成见，灵活变通。