Restful web服务

做:

• hypertext-driven (作为应用程序状态引擎的超媒体-HATEOAS)。
• 花大部分时间和精力识别资源并精心设计媒体类型来表示它们。
• 将整个URI视为您的资源标识符,并假设它将来会发生变化。
• 提供所有选项,以便在您的应用程序中作为表示中的链接继续。
• 把你的应用程序想象成一个会被客户“爬网”或“浏览”的网站。

不要:

• 在API文档中发布URI模板。如果您必须有查询参数的模板,请确保它们是媒体类型定义的一部分。
• 将应用程序视为由四个动词作用的URI的集合。
• 向客户端提供mime类型,如“application/xml”或“application/json”。

打个比方,你的API应该更像你客户的GPS,而不是地图。你只能向客户提供附近街道的名称。但从那时起,他们只能做你的应用程序说他们可以在任何给定的点。

大多数“RESTful”API不遵循这种模式。如果有,请参阅 Sun Cloud API 及其 backstory .

您希望避免的一些事情是:

• 忽略缓存
• 通过GET(或POST)挖掘所有信息
• 忽略MIME类型

这里有一篇很好的文章讨论了其他一些反模式:

http://www.infoq.com/articles/rest-anti-patterns

这是一个宽泛的问题,但我会试一试。首先,只使用HTTP动词来表示该操作的意图。不要使用URL参数发布到URL,该参数基本上会覆盖帖子并将其转换为GET或DELETE。这就是SOAP的工作原理(一切都是帖子)。

本文详细介绍了一些区别RPC和REST的设计决策:

http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/28/47067.aspx