HATEOAS背后的核心思想之一是客户端应该能够从单一入口点URL开始,并发现所有可用的公开资源和状态转换.虽然我可以很好地看到它如何与HTML和人类在浏览器后面点击链接和"提交"按钮,我被问及这个原则如何应用于我(非)幸运地处理的问题.
我喜欢RESTful设计原则如何在论文和教育文章中呈现,这一切都有意义,如何获得一杯咖啡就是一个很好的例子.我将尝试遵循惯例,并提出一个简单且没有繁琐细节的例子.我们来看看邮政编码和城市.
假设我想设计RESTful api,用于通过邮政编码查找城市.我想出了嵌套在邮政编码中的称为"城市"的资源,因此GET on http://api.addressbook.com/zip_codes/02125/cities返回包含代表Dorchester和Boston的两条记录的文档.
我的问题是:如何通过HATEOAS发现这样的网址？暴露所有~40K邮政编码的索引可能是不切实际的http://api.addressbook.com/zip_codes.即使拥有40K项目索引并不是一个问题,请记住我已经制作了这个例子,并且有更大规模的集合.
基本上,我想要暴露不是链接,而是链接模板,而不是像这样:http://api.addressbook.com/zip_codes/{:zip_code}/cities,这违背了原则,依赖于客户拥有的带外知识.
假设我想通过某些过滤功能公开城市索引:
GET on http://api.addressbook.com/cities?name=X将仅返回名称匹配的城市X.
GET http://api.addressbook.com/cities?min_population=Y仅会返回人口相等或大于的城市Y.
当然这两个过滤器可以一起使用:http://api.addressbook.com/cities?name=X&min_population=Y.
在这里,我不仅要公开url,还要公开这两个可能的查询选项以及它们可以组合在一起的事实.如果没有客户端对这些过滤器的语义的带外知识以及将它们组合到动态URL中的原则,这似乎是根本不可能的.
那么HATEOAS背后的原则如何帮助制作这样简单的API真的是RESTful？
我建议使用 XHTML 表单：
\n\nGET /\n\nHTTP/1.1 OK\n\n<form method="get" action="/zip_code_search" rel="http://api.addressbook.com/rels/zip_code_search">\n <p>Zip code search</p>\n <input name="zip_code"/>\n</form>\n\nGET /zip_code_search?zip_code=02125\n\nHTTP/1.1 303 See Other\nLocation: /zip_code/02125\nHTML 中缺少的rel是form.
看看这篇文章：
\n\n\n\n\n总而言之，考虑将 XHTML 作为 RESTful 服务的默认表示形式有多种原因。
\n<a>首先，您可以利用、\n 等重要元素的语法和语义<form>，而<input>不是发明自己的元素。其次，您最终会得到感觉很像网站的服务，因为用户和应用程序都可以浏览它们。XHTML 仍然由人类\xe2\x80\x94 解释，它只是开发期间的程序员\n 而不是运行时的用户。这简化了整个开发过程，并使消费者更容易了解您的服务的工作原理。最后，您可以利用标准的 Web\n 开发框架来构建 RESTful 服务。
另请查看OpenSearch。
\n\nHTTP/1.1 200 OK\nContent-Location: /zip_code/02125\n\n<html>\n<head>\n<link href="/zip_code/02125/cities" rel="related http://api.addressbook.com/rels/zip_code/cities"/>\n</head>\n...\n</html>\n| 归档时间： |
|
| 查看次数： |
5413 次 |
| 最近记录： |