与一半的Web开发人员社区一起,我一直在努力真正地确定REST风格.更具体地说,我一直试图就一个纯粹的RESTful架构在Web浏览器和应用服务器之间的实际可行性形成一些看法.
作为我学习努力的一部分,我一直在研究REST的一些在线示例,特别是在这种情况下的Twitter.在他们的API文档中,他们讨论了各种"REST API方法".
除了拥有RESTful URL结构之外,我正在努力理解其中大部分实际上是RESTful.例如,考虑一个对http://twitter.com/favorites的简单GET请求.
在REST的纯实现中,我希望对该URL的相同请求(无论发起客户端如何)返回相同的响应.但是,在这种特殊情况下,我们显然会看到不同的响应,具体取决于我们当前经过身份验证的用户,这意味着我们的请求在生成响应之前连接到服务器上的某种形式的客户端状态.
希望这为我的问题提供足够的上下文 - 真的可以称之为"REST"吗？我得到的印象是,Web浏览器和应用程序服务器之间90%的所谓RESTful实现都表现出同样的不一致性,其中忽略了存储在服务器上的客户端状态限制.
Twitter几乎破坏了每个REST约束.您http://twitter.com/favorites根据经过身份验证的用户返回不同结果的示例是Twitter违反"资源标识"约束的示例.每个有趣的资源都应该有唯一的标识符.我的Twitter收藏夹和您的Twitter收藏夹是两种不同的资源,因此应该有两个不同的URI.
这实际上与幂等性无关.幂等性是指能够多次发出相同的请求并且具有相同的效果.甚至Twitter都尊重幂等性.如果我多次获得我的最爱,我仍然会收到我的最爱.我做GET的次数不会影响结果.
Twitter还有许多其他方式可以打破REST限制.这些问题中的许多问题已在此处讨论过.
更新 在仔细阅读Twitter api文档之后,实际上有一种替代URI格式可以正确识别收藏夹资源. 这里他们展示了如何创建一个URL:
http://api.twitter.com/1/favorites/bob.json
从RESTful开始还有很长的路要走,但至少这是朝着正确方向迈出的一步.
在这种情况下,幂等性是一个棘手的词.即使您正在检索单个推文,如果该推文可编辑且有人编辑它,您将得到不同的结果.检索列表时,我当然希望有一条推文来检索最新的列表.
将幂等性视为在不引起副作用的情况下做某事的能力可能更有帮助.因此,GET在这个意义上是幂等的,但POST不是.
来自维基百科:
在计算机科学中,术语"幂等"用于描述可以安全地多次调用的方法或子程序调用,因为一次或多次调用该过程具有相同的结果; 也就是说,在任意数量的方法调用之后,所有变量都具有与第一次调用之后相同的值.任何没有副作用的方法或子程序也是幂等的.
也来自维基百科:
方法PUT和DELETE被定义为幂等的,这意味着多个相同的请求应该具有与单个请求相同的效果.
与此相反,POST方法不一定是幂等的,因为发送相同POST请求多次可以进一步影响状态或造成进一步的副作用(例如金融交易[例如客户得到错误的同一产品带电两次]).
也可以看看:
我如何解释REST我的妻子
http://tomayko.com/writings/rest-to-my-wife
京公网安备 11010802040832号 | 京ICP备19059560号-6 