博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
端到端的超媒体REST API设计
阅读量:6762 次
发布时间:2019-06-26

本文共 1009 字,大约阅读时间需要 3 分钟。

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

\\

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

\\

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

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

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

\\

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

\\

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

\\

查看英文原文

转载地址:http://kebeo.baihongyu.com/

你可能感兴趣的文章
我是怎样看待微博的
查看>>
论《我是如何安慰女友的》
查看>>
nullnull用宏定义swap(x,y)
查看>>
【Javascript】类,封装性 -- 1
查看>>
Mono for Android安装配置破解
查看>>
uploadfy 常见问题收集
查看>>
WPF----数据绑定
查看>>
子类化GetOpenFileName/GetSaveFileName, 以及钩子函数OFNHookProc的使用的简要说明
查看>>
C语言中判断int,long型等变量是否赋值的方法
查看>>
leetcode -- Longest Valid Parentheses
查看>>
详解JAVA输出Hello World
查看>>
概率问题随笔
查看>>
关于在堆中创建字符串对象的疑惑
查看>>
poj1077(康托展开+bfs+记忆路径)
查看>>
hibernate 树状映射
查看>>
值得 Web 开发人员收藏的20个 HTML5 实例教程
查看>>
移动设备、手机浏览器Javascript滑动事件代码
查看>>
@Resource注解
查看>>
Android(Linux) 网卡名修改
查看>>
Ubuntu 中的VI和vim
查看>>