BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

端到端的超媒体REST API设计

| 作者 Jan Stenberg 关注 29 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2015年7月13日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

Jimmy Bogard在他的一系列博客帖子中表示:REST是一种定义良好的架构风格,它能够为我们带来许多益处,但也经常被误用于描述各种各样的Web API。他特别着重描述了实现一个从服务器到客户端的端到端超媒体解决方案所必需的步骤,包括如何选择一种富超媒体的媒体类型(media type)。

Bogard是一位微软的MVP,他强调说,REST以及超媒体这种REST的约束会大大提高客户端与服务端API设计的复杂性。他认为只有在某些场景中才值得这么做,尤其是在客户端与服务端分别独立进行设计的情况下。如果客户端与服务端代码共存于一个源代码控制库,并且还是同时进行部署的,那么超媒体在这种情况下为他提供不了多少价值。

至于如何选择一种媒体类型,Bogard认为有这么三种选择:

  • 选择某个现有标准。
  • 对某个现有标准进行扩展。
  • 设计属于自己的媒体类型。

考虑到设计一种媒体类型所需的精力,这已远不是在一个项目中就能够完成的工作了,因此他倾向于尽可能选择一种标准的媒体类型。在对不同的媒体类型的能力进行比较时,他提到了Mike Amundsen所设计的H Factor,这项工具能够衡量某个媒体类型对于超媒体的支持等级,帮助他做出适合于当前场景的最佳选择。不过,他往往发现所选择的媒体类型无法满足他的所有需求,因此不得不对所缺失的部分进行扩展。

Bogard认为服务端的设计与实现是非常直观的,这与创建一个纯粹的JSON API差别不大,只是增加了一个更丰富的超媒体模型的复杂性。通常来说,包含所选择的媒体类型的API在实现之后还要接受调用者的检验,从客户端的角度对其进行验收。

至于客户端方面,Bogard在文中提到,他所见到的大多数REST示例虽然包含了服务端的API,但往往未能提供实际的实例,使客户端了解如何调用它们。在Bogard的示例中,他创建了一个web客户端,其中包含了一个基本的导航视图。 视图中包括了一些信息表,用户可通过这些信息配合在服务端响应中所包含的关系与链接查看详细的内容。服务端返回的响应中包括了大量的元数据,为了保持REST风格所提供的松耦合能力,客户端必须由这些元数据所驱动。但Bogard依然认为,客户端应当为某个特定的目的而设计,要打造一个泛用目的的客户端是非常无趣的。除了使用jQuery设计客户端之外,他还描述了如何使用React设计并实现客户端,由于React带有面向组件的特性,因此在Bogard看来,它能够非常完美地配合超媒体的使用。

查看英文原文Design of a Hypermedia REST API Server and Consuming Client

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT