表现良好的 RESTful 客户端交互

我有一个关于实现严格遵守 REST 架构原则的数据访问客户端的似乎相当简单的问题。首先，我们假设我有一个运行良好的 REST API，我想使用 Django 应用程序来使用它。我将首先发现哪些服务可用（为后续内容编辑）:

GET example.com/services/ HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<services>
  <service>
    <name>Widgets</name>
    <link>http://example.com/services/widgets/</link>
    <item_link>http://example.com/services/widgets/{widget_id}/</item_link>
  </service>
  <service>
    <name>Factories</name>
    <link>http://example.com/services/factories/</link>
    <item_link>http://example.com/services/factories/{factory_id}/</item_link>
  </service>
  ...
</services>

现在，由于我正在构建一个基于使用此 API 的 Django 应用程序，我将如何继续以 REST方式继续探索这些服务？为了遵守 REST 原则，我的应用程序必须由接收到的超媒体驱动。我想第一步很简单——通过给定的名称与服务交互。我设置了一个 Django 视图，如下所示：

def get_service(request, service_name):
    doc = etree.parse(urllib.urlopen('http://example.com/services/'))
    uri = doc.xpath("service/name[.='%s']/following-sibling::*" % service_name)[0].text
    ...

我将从中执行另一个请求（为后续内容编辑）:

GET example.com/services/widgets/ HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<widgets>
  <item_link>http://example.com/services/widgets/{widget_id}/</item_link>
  <widget>
    <id>1</id>
    <name>Whizbang Foobar</name>
    <link>http://example.com/services/widgets/1</link>
  </widget>
  ...
</widgets>

现在，我将在渲染的 Django 模板中显示一个简单的小部件列表。但从这里开始，我如何继续以 REST方式与该服务交互？也许我已经把自己搞糊涂了，但唯一的办法就是合理的我能想到的办法是实现大量应用程序视图或瘦 Django 数据模型来持久保存服务 URI。

我主要担心的是，如果不严格遵守 REST 架构准则，这是微不足道的，但我觉得我在尝试这样做时完全错过了机会。我知道设计正确的 REST API 和客户端并不“容易”，但似乎我迫切需要一个类似的示例来完成实际的实现。

对于这个问题的冗长和冗长以及不可避免的枯萎读者的捂脸，我深表歉意。

跟进：

以下是实现这些交互的有效方法（使用 URI 模板）吗？出于演示目的（代替更抽象的实现），使用另一个 Django 视图来检索资源集合项：

def get_item(request, service_name, item_id):
    doc = etree.parse(urllib.urlopen('http://example.com/services/'))
    uri = doc.xpath("service/name[.='%s']/following-sibling::item_link" % service_name)[0].text
    ...

那么接下来的请求：

GET example.com/services/widgets/1 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<widget>
  <id>1</id>
  <name>Whizbang Foobar</name>
  <tags>foo bar baz ham eggs</tags>
  <index_link>http://example.com/services/widgets/</index_link>
</widget>

我主要担心的是，如果不严格遵守 REST 架构准则，这是微不足道的，但我觉得我在尝试这样做时完全错过了机会。我知道设计正确的 REST API 和客户端并不“容易”，但似乎我迫切需要一个类似的示例来完成实际的实现。

我能找到的最好的例子是太阳云API http://kenai.com/projects/suncloudapis/pages/Home。大多数文档描述了系统使用的各种媒体类型，这似乎是实现此类目标的关键。

我发现在开发 API 的同时编写客户端会很有帮助。这样您就可以立即发现可能导致 API 编码困难的因素并解决问题。

这并不容易。如果您遵循 HATEOAS 约束得出其逻辑结论，您定义的每种媒体类型都将由一系列客户端之一处理。如果您可以使所有资源遵循类似的行为模式，那么您编写客户端的工作就会变得更加容易。

例如，您可以定义一个媒体类型“索引”，仅列出相关资源。索引定义用于分页、获取列表中的项目、按名称查找项目等的链接。

然后，您可以定义一个名为“Item”的基本媒体类型。 Item 有一个链接，用于显示其父 Index、更新/删除自身等。然后，您的资源 Widget 可以由两种不同的媒体类型表示 - 一种是 Index，另一种是基于 Item。

您可以首先实现一个处理 Index 媒体类型的类。然后，您可以编写一个基类来处理所有常见的 Item 媒体类型行为。最后，您可以编写一个 Widget 客户端来处理所有特定于 widget 的行为并扩展 Item 客户端。这些客户端可以按照其编写语言的惯用方式公开其功能（更多链接和数据字段的可用性）。

处理来自服务器的响应只需将响应的 MIME 类型与您编写的客户端之一进行匹配即可。

换句话说，即使您的服务的客户端作为一个整体将由许多范围有限的客户端组成，但它们每个都将基于共同的行为，因此可以以 DRY 方式实现。