Rig*_*ala 6 rest http url-design web
每个Web应用程序 - 每个Web站点 - 都是一项服务.(...)使网站易于使用的网站功能也使网络服务API易于程序员使用.
Richardson和Ruby,"RESTFul Web Services"
根据我的意图,一个也是Web服务的Web站点提供其资源的多种表示,具体取决于用户代理请求的内容.可以这么说的API是网站本身,不是单独提供的.
对于许多流行的"REST API"而言,情况并非如此.例如,Twitter的API位于http://api.twitter.com/1/,URI中的"1"是API本身的版本.Socialcast还在https://demo.socialcast.com/api/上提供了REST API ,第三级名称是它所处理的网络的名称.
这对我来说似乎不对.如果我的博客位于http://www.example.com/blog,我不需要在其他位置提供API,仅为机器人提供JSON.而不是http://www.example.com/blog/posts/和http://api.example.com/blog/posts,两个不同的URI,我应该只有前者,并且可以使用多种表示,其中application/json对于我希望提供给我的用户的JSON API.
示例1:浏览器询问我博客上的帖子;
请求:
curl -i \
-H "Accept: text/html" \
-X GET \
http://www.example.org/blog/posts/
响应:
200 OK
Content-Type: text/html; charset=utf-8
<html><body><h1>Posts</h1><ol><li><h2>My first post ...
示例2:相同的URI,但这次机器人发出请求;
请求:
curl -i \
-H "Accept: application/json" \
-X GET \
http://www.example.org/blog/posts/
响应:
200 OK
Content-Type: text/html; charset=utf-8
{
"posts": [
{
"id": 1,
"title": "My first post" ...
API的版本号应该在请求标题的"Accept"字段中编码,最重要的是避免像Twitter那样强烈输入URI("statuses/show.json？id = 210462857140252672"或"status/show/210462857140252672.json" ").
通过采用统一的方法,我可能会失去一些灵活性(但是,Cool URI永远不会改变吗？),但我认为坚持REST(或者至少我对它的解释)将提供更多的好处.
哪种方法更正确:将API和网站分开,还是将它们统一起来？
这里没有对错.当您的API开发受特定客户端要求驱动时,REST和RFC过于紧密可能会很困难.
实际上,与API客户端相比,人类用户具有不同的行为模式,因此需要不同的处理.最生动的区别在于,许多API都是数据密集型,专为批处理操作和数据转储而设计,而人类用户的应用程序则更具"反应性",并且通常按要求逐步执行操作.因此,在许多项目中,API URL设计经过优化,以避免在多个网络往返和重复存储调用上浪费客户端和服务器资源.
在幕后,API实现通常具有与核心应用程序不同的设计,针对API提供的操作类型进行了优化.例如,API实现可以使用单独的缓存策略.现在,如果您拆分代码,则可能需要创建仅处理API调用的主机群集.这就是将API放在另一个域上变得有利于负载管理的地方:单独的域允许在高负载站点上实现更简单的负载平衡.相比之下,当您在同一域名上使用/ api URL前缀(但具有单独的集群)时,您需要一个智能(L7感知)负载均衡器来完成在API和Web前端集群之间拆分请求流的工作,但是这种负载平衡器更贵.
因此,可能有非常好的技术原因,为什么Twitter之类的人将API分开,但对其他实现的引用可能不适用于您的项目.如果您处于设计的早期阶段,您可能希望从同一域上的统一URL方案开始,但最终您可能会发现有很好的实际用例可以让您更改方法,然后......重构.
PS这里有关于版本控制的冗长讨论 - API版本控制的最佳实践？
PSS我发现强类型的URL有助于快速调试.您可以使用.json将URL放入浏览器中,并快速获取结果,而无需切换到命令行.但同意你的看法,"接受"标题是首选方法
API的PSSS SEO？我可以看到一个好的URL设计如何有益,但对于搜索引擎,如果您的服务在相同的路径/域名上提供多种输出格式,它可能无关紧要.在一天结束时,搜索引擎是为人类用户构建的,而人类用户不使用XML和JSON.
| 归档时间： |
|
| 查看次数： |
384 次 |
| 最近记录： |