将“方法”建模为反射资源会违反REST风格吗？

时间：2011-01-20 20:38:31

标签： web-services http rest

我是REST新手，很可能正在推动/越过限制......

假设我们有典型的订单示例：

GET /Order/12345

现在我想发布一个反射资源来描述属性，方法，关系方面的“订单”类型。

GET /Reflection/Type/Order

除其他外，回复可以包含“Order”类型方法“foo”的反射对象表示的URI 

/Reflection/Type/Order/Method/foo

接下来我们可以POST到该URI以使用/ call / post-to方法...如果方法需要参数，它们将在正文中传递。

POST /Reflection/Type/Order/Method/foo

我的推理：

  • 查看对象/概念/事物 反射层为资源
  • “类型”，“方法”是名词
  • “foo”是一个id＆lt; ============这可能是（或者是）问题
  • GET / Reflection / Type / Order / Method返回“Order”类型的所有Method表示
  • 反射层对象的GET / PUT / DELETE仍然具有完美的意义（幂等性等）

我现在倾向于拥有一个事务队列并在那里发布一个事务...... 

POST /TransactionQueue

正文将包含表示方法foo（/ Reflection / Method / foo）的反射资源的URI，任何对象资源的URI和非对象参数的正常值。

问题：这种解释是否可以容忍，或者是否以最糟糕的方式违反了REST风格？

如果以上是假的，我需要一些关于RESTful接口的提示：

  • 物体
  • 描述公开对象具有哪些属性/方法/关系的反射层
  • 一种在对象上执行方法的方法

更新：关于HATEOAS的This非常有趣......

更新：寻找Burton Group的Peter Lacey的RestEasy powerpoint

更新：播客http://www.udidahan.com/2008/03/16/podcast-rest-messaging-enterprise-solutions/

更新：预订“Restful web services cookbook”

更新：预订“实践中的休息”

2 个答案:

答案 0 :(得分：0)

这种设计不会导致非常Restful的系统，它不提供统一的界面。实际上，对“在对象上执行方法的方法”本身的所述要求违反了为客户端提供统一接口的概念。您当然会在幕后对象上执行方法，但是将该模型推送到交互层会违反为客户提供统一接口的原则。

所有交互都应采用GET，PUT，DELETE和POST资源的形式。

正如您所发现的那样，超文本非常重要，用于在获取资源后通知客户端相应的后续选择。有许多格式可以帮助您描述您要查找的关系类型，例如尝试使用RDFa。

答案 1 :(得分：0)

慢慢与HATEOAS一起到达那里：

  • 网络已经是RESTful。
  • 您只需要一个入口点网址
  • 恕我直言网址应与资源/名词相对应。拥有酷炫，不透明，无用的URL是完全没问题的，它不会泄露任何语义。此外，客户端被迫通过正式描述来解释超链接的语义，而不是解释URL本身。
  • 超链接的语义用（标准化的）形式描述表示。这是超链接的语言，它是客户端需要知道的唯一语言。例如RDF，Atom等。
  • 只需将客户端视为专门的浏览器，只知道（自定义）链接类型和媒体类型。
  • 除了在响应中收到的链接之外，客户端不能执行任何操作。它本身不构造任何URL。

特别启发：

相关问题
最新问题