20、设计可读写的用户账户资源服务

设计可读写的用户账户资源服务

在设计可读写的资源导向型服务时，我们需要一系列步骤来确保服务的有效性和安全性。以下将详细介绍如何设计用户账户资源服务。

1. 确定数据集

大多数带有用户账户的网站会将个人信息与账户关联，如姓名或电子邮件地址。但在地图服务中，与用户账户关联的信息只有两项：
- 账户名称
- 用于访问账户的密码

每个用户账户还可能有一些下属资源（如行星上的自定义地点），不过这部分内容后续再考虑。目前，我们只需要一种识别特定用户账户的方式（用户名），以及客户端提供与特定用户账户关联的凭证的方式（密码）。

由于不跟踪任何个人信息，从传统意义上来说，将其称为“用户账户”也只是一种习惯。实际上，也可以称之为“受密码保护的注释集”，但为了便于可视化服务和进行用户账户系统的扩展，还是使用传统术语。

2. 将数据集拆分为资源

之前数据集较大且模糊，如“行星、地点和地图”，拆分资源是一个较大的步骤。而现在数据集较为受限，仅为“用户账户”。

将每个用户账户作为一个资源进行公开。这些新资源属于特定类型的资源，是服务暴露底层用户对象的门户。有些网站可能会将用户账户列表本身作为一次性资源公开，或者提供算法资源让客户端搜索用户列表，但这里不做这些处理。

3. 使用 URI 命名资源

由于只有一种资源类型，这一步相对简单。用户账户将通过以下形式的 URI 进行公开：https://maps.example.com/user/{user - name}。

4. 暴露统一接口的子集

这是一个新步骤。在设计只读资源