关于超媒体API的3个置疑

发布时间：2020-02-11 02:13:02 阅读：次来源：板弹簧厂家

在API中引用URL而不是ID是个好主意，这样会使得编写一个客户包装器的时候更方便，因为你不用插入URL模版。因此你可以用t(response[:PErson][:url]) 代替 t(“/people/#{response[:person][:id]}”)。

但是现在用URL代替ID的好处被过分渲染了，它没法保证这样就不出问题，它对于规范API客户端没有任何的好处，而且对于提高发现性没什么太大好处。

保证不出问题?

根据超媒体的说法，你可以不用更新任何客户端就改变你的URL，但这是基于一个假设：每个API调用每次都将穿过前门以及导航到他们需要的页面。

但事实不是这样的，如果我想向Basecamp的一个项目请求一条消息，我得做这样的事情：“GET /projects ”, “ GET /projects/1”, “GET /projects/1/messages”, “ GET /projects/1/messages/2”，这个刚开始凑效，但是我一旦bookmark最近的那条URL(因为我准备稍后对它做些评论)。如果你的任何客户也像你一样存储一个URL, 一般人不会随便去改URL，却发现URL变了，它存的URL也就没用了。

而之前API之所以在Web端如此成功，是因为它相当稳定，遵循W3C说的：“保证URL不改变”，但是超媒体APIs一但允许改变URL的话，肯定会有一系列问题的。

提高发现性?

好的API docs会尽可能地解释一个资源的属性，如果我们可以只通过告诉用户用“GET /”然后他们自己去摸索所有的选项就能很好地派生所有资源的话。

我怎么知道我偶然发现的数据能包含一切可能的数据。如果恰好我要求的项目没有任何附带文件?我怎么知道怎么去寻找以及怎么添加新的东西?

标准化API客户端?

关于你可以写一个客户端以任何方式来访问不同APIs的想法，这个忽视了一个很重要的事情，不同的APP是做不同的事情的，不能因为有一个现有的资源到子资源的标准，然后你就可以编写一个通用的客户端然后它会自动知道如何处理任何API。

一个所谓“通用”的API不会知道Flickr照片和Basecamp项目的区别。

每一个单个的应用程序需要一个定制的API客户端，这个客户端需要知道每个资源的属性以及怎么区别对待他们。

所以总的来说，下面是3个简单的解决方案(如果不需要一个规范或涉及IETF)，

1. 不要改变你的API URLs

2. 文档化API

3. 提供一个自定义客户端包装器

所以还是在ID里面使用URL吧，因为这个还是比较方便，而我们之前也尝试着标准化API，但导致了额外的WS-dEAthstar建设，所以你们不要重复这个错误，有时候少点标准化思想多点调查就会让你少走一些弯路。