File API 的架构和实现

　　开放API 服务是上海交通大学建设数字大学的重要基础设施之一，是一组包括了获取/ 管理个人信息、通知、任务、教参信息、邮件、非结构化存储等功能的开放接口，并还在不断增加新的功能。所有的API 均采用REST 风格，使用JSON 作为数据交换的格式，使用OAuth 进行授权保护，其中File API 提供了如下一组接口：1. GET https://api.sjtu.edu.cn/v1/file/{id}。用于下载。在已知文件id 的情况下，可以通过这个接口获取文件数据。

　　2. GET https://api.sjtu.edu.cn/v1/file/{id}/thumb/WxH。用于下载缩略图。对于图像文件，File API 能够产生指定分辨率的缩略图，这个接口用于下载产生后的缩略图数据，W 和H 为图像的宽度和高度。

　　3. GET https://api.sjtu.edu.cn/v1/file/{id}/meta。用于获取文件信息，如文件名、大小、创建时间、修改时间等。

　　4.POST https://api.sjtu.edu.cn/v1/file/{id}/meta。用于修改文件信息。

　　5. PUT https://api.sjtu.edu.cn/v1/file。用于上传文件。

　　通过这组接口，应用系统可以上传它需要管理的文件数据，获取并保存API 返回的文件id，并在需要的时候重新下载使用。

　　File API 的实现和应用的架构如图1所示。如前面所述，File API 是对云存储接口的再封装，因此它通过云存储的API完成数据实际的上传和下载，File API 是在OAuth 的授权保护下工作，因此它必然需要有途径来验证access token 的合法性。目前我们提供的API 都由网络中心自己开发并运维，因此我们选择了和OAuth服务共用一个数据库(OAuth DB) 的方式来实现。这里需要注意的是，如果API 服务由第三方提供，共享数据库的方式就不能采用，需要提供另外的方式来提供accesstoken 的验证，如由OAuth 服务提供一个Web Service 接口。最后，文件的meta 信息，如大小、文件名、创建时间等，使用一个Redis 数据库来保存，不依赖云存储。

图1File API 架构

　　一般的数据流程为：

　　当用户访问应用系统需要上传文件时， 应用系统首先从OAuth 服务获取access token，然后使用该access token 调用File API 的上传接口，将数据上传到File API，File API 验证了access token 的合法性后，将文件数据通过云存储API 上传到云存储，并产生一个代表该文件的id(GUID) 返回给应用系统，同时将文件的信息（在云存储中的位置、大小、名称等待）保存到Redis 数据库。最后应用系统用自己的方式保存这个ID。

　　当用户访问应用系统需要下载文件时，应用系统首先用自己的方式查询到要下载的文件id，然后使用该文件id 调用File API 的下载接口，而File API 先从Redis 数据库中查询到该id 对应的文件信息，然后通过云存储API 从云存储获取文件数据返回给应用系统，最后由应用系统返回给用户。

　　可以发现， 下载接口并不需要从OAuth 获取access token，只需要提供文件id。之所以这样设计，是因为文件id 是GUID，只要不把它暴露出去，文件数据的安全是可以保障的。当应用系统只希望它自己才能访问这些文件时，它可以选择不对外透露这些文件id，所有对这些文件数据的访问只能通过应用系统才能进行。而当应用系统认为文件数据的完全可以公开时，它可以将构造好的下载URL 交给用户的浏览器，因为下载URL 中不含有access token，因此不必担心access token泄露。这种方式下，用户的浏览器将直接从File API 请求下载数据，不再通过应用系统中转，对减轻应用系统压力有很大帮助。