这似乎是我最难以绕过头脑的REST主要内容.据我所知,在设计一个rest api时,大部分工作都应该用于设计/描述应用程序的超文本.指向这个主体的真实世界应用的指针？原子协议如何应用此主体？有人可以用简单的方式解释如何将其应用于假设的购物车休息api.
Dar*_*ler 12
在尝试解释超媒体时,我喜欢使用通过路标与地图在汽车中导航的示例.我意识到它并没有直接回答你的问题,但它可能有所帮助.
当驾驶汽车并到达特定的十字路口时,您将获得路标以指示您可以从该点开始前往何处.同样,hypermedia根据您当前的状态为您提供一组选项.
传统的基于RPC的API更像是地图.使用地图,您倾向于根据一组静态道路数据计划您的路线.地图的一个问题是它们可能变得过时,并且它们不提供有关交通或其他动态因素的信息.
路标的优点在于它们可以在运行中进行更改,以便在施工时绕行交通或控制交通流量.
我并不是说路标总是比地图更好的选择.显然有利有弊,但了解两种选择都很有价值.超媒体也是如此.它是传统RPC接口的有价值的替代品.
考虑自己浏览常规网站.当您访问时,您阅读了页面的内容,并根据您阅读的内容和您想要做的事情,您可以按照页面上的各种链接进行操作.这真的是"超文本作为应用程序状态引擎"归结为的核心.在此示例中,应用程序状态是您头部的状态和您所在的页面.在此基础上,您将遍历更多链接,这会改变您头脑中的应用程序状态.
还有另外一个元素,请注意:它的另一面是你不应该猜测那些URI:页面中应该有足够的上下文来推断URI(例如应用程序对内容的信息)类型,以及诸如URI模板之类的东西,或者应该存在要遵循的URI.除此之外,RESTful HTTP应用程序不应该关心URI的结构.
更新:为了扩展,HTML表单也展示了HATEOAS.使用GET的表单类似于URI模板的使用.并且HATEOS不仅限于使用HTTP GET遍历链接:使用POST(或其他一些方法,如果浏览器恰好支持它)的表单可以描述要发送到服务器的表示.
| 归档时间： |
|
| 查看次数： |
1535 次 |
| 最近记录： |