这个问题更多的是关于服务架构策略的问题，我们正在构建基于后端rest服务的大型网络系统。我们目前正在尝试建立一些内部标准，以便在开发休息服务时遵循。

一些查询返回实体列表，例如让我们考虑我们有图片库检索服务:/gell_all_galeries，返回下一个响应:

<galleries>
   <gallery>
      <id>some_gallery_id</id>
      <name>my photos</name>
      <photos>
          <photo>
                <id>123</id>
                <name>my photo</name>
                <location>http://mysite/photo/show/123</location>
                ......
                <author>
                     <id>some_id</id>
                     <name>some name</name>
                     .......
                <author>
          </photo>
          <photo> ..... </photo>
          <photo> ..... </photo>
          <photo> ..... </photo>
          <photo> ..... </photo>
    </photos>
  </gallery>
  <gallery> .... </gallery>
  <gallery> .... </gallery>
  <gallery> .... </gallery>
  <gallery> .... </gallery>
</galleries>

正如您在这里看到的那样，响应非常大而且很重，而且我们并不总是需要这么深的信息级别。通常的解决方案是使用或 http://ru.wikipedia.org/wiki/Atom每个图库的元素而不是完整的图库数据:

<galleries>
   <gallery>
      <id>some_gallery_id</id>
      <link href="http://mysite/gallery/some_gallery_id"/>
   </gallery>
   <gallery>
      <id>second_gallery_id</id>
      <link href="http://mysite/gallery/second_gallery_id"/>
   </gallery>
  <gallery> .... </gallery>
  <gallery> .... </gallery>
  <gallery> .... </gallery>
  <gallery> .... </gallery>
</galleries>

接下来是第一个问题:也许我们甚至不应该使用 and 类型，而只对返回列表对象的所有资源使用通用 and:

 <list>
  <item><link href="http://mysite/gallery/some_gallery_id"/></item>
  <item><link href="http://mysite/gallery/other_gallery_id"/></item>
  <item>....</item>
</list>

第二个问题，在用户尝试检索有关某个具体画廊的信息后，他将使用例如 http://mysite/gallery/some_gallery_id链接，他应该看到什么结果？

应该是:

   <gallery>
      <id>some_gallery_id</id>
      <name>my photos</name>
      <photos>
          <photo>
                <id>123</id>
                <name>my photo</name>
                <location>http://mysite/photo/show/123</location>
                ......
                <author>
                     <id>some_id</id>
                     <name>some name</name>
                     .......
                <author>
          </photo>
          <photo> ..... </photo>
          <photo> ..... </photo>
          <photo> ..... </photo>
          <photo> ..... </photo>
    </photos>
  </gallery>

或:

   <gallery>
      <id>some_gallery_id</id>
      <name>my photos</name>
      <photos>
          <photo><link href="http://mysite/photo/11111"/></photo>
          <photo><link href="http://mysite/photo/22222"/></photo>
          <photo><link href="http://mysite/photo/33333"/> </photo>
          <photo> ..... </photo>
    </photos>
  </gallery>

或

   <gallery>
      <id>some_gallery_id</id>
      <name>my photos</name>
      <photos>
          <photo>
               <link href="http://mysite/photo/11111"/>
               <author>
                    <link href="http://mysite/author/11111"/>
               </author>
           </photo>
          <photo>
               <link href="http://mysite/photo/22222"/>
               <author>
                    <link href="http://mysite/author/11111"/>
               </author>
           </photo>
          <photo>
               <link href="http://mysite/photo/33333"/>
               <author>
                    <link href="http://mysite/author/11111"/>
               </author>
           </photo>
          <photo> ..... </photo>
    </photos>
  </gallery>

我的意思是如果我们使用链接而不是完整的对象信息，我们应该去多深？我应该向作者展示内部照片等等。

可能我的问题模棱两可，但我想做的是在这种情况下制定总体策略，供所有团队成员在未来遵循。

最佳答案

“我应该如何设计我的媒体类型”确实没有正确或错误的答案。但是，在选择现有媒体类型和设计新媒体类型时，有一些非常重要的准则。

RESTful 系统通过谨慎使用缓存实现可伸缩性。设计您的资源以将内容分解为具有相似数据波动性的 block 。例如，在您的场景中，您有一个包含照片的画廊列表。我的猜测是您不会经常添加/删除画廊，但您会定期添加/删除照片。因此，确保您可以获得没有照片信息的画廊列表是有意义的。这将使缓存该响应变得容易。

优化响应大小对性能很重要，但缓存更为重要。通过线路发送 0 字节总是更有效。

即使照片列表可能会更频繁地更改，您仍然可以有效地使用缓存。通过使用 if-modified-since header 或 etags，您不会节省网络往返，但您可以通过不传输未更改的表示来节省大量带宽。

设计适用于所有情况的资源非常困难，因此我建议您不要尝试。设计适合您的特定用例的资源。如果出现其他用例，请创建新资源来处理这些用例。

创建没有错:

/gallery/foo/quickview
/gallery/foo/detailedview
/gallery/foo/justlinks

您想使用一个网络框架，使创建新资源变得真正容易和便宜。资源很少会与您的域实体具有一对一映射，因此您可以根据需要随意创建任意数量的资源。

我最后的评论是关于媒体类型的选择。您真的应该考虑使用像 Atom 这样的服务来提供这样的服务。 Atom 是管理事物列表的理想选择，它拥有处理照片等媒体元素的所有机制。

大多数人在开始使用 REST 服务时都习惯了他们可以直接将 application/xml 或 application/json 作为媒体类型交付的想法。在某些特殊情况下这是完全可行的，但是当您开始实现更多 REST 约束时，您会发现这些通用媒体类型格式将限制您在许多情况下可以获得的好处。目前，不要太担心，只要知道选择“真正的”媒体类型总是更安全的，比如 application/xhtml、RDF 或 Atom，如果你选择 application/xml，你可能会遇到困难稍后。

关于xml - RESTful服务架构问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2996934/