xml – RESTful服务架构问题

发布时间：2020-12-16 23:12:40 所属栏目：百科来源：网络整理

导读：这是关于服务架构策略的更多问题,我们正在构建基于后端休息服务的大型Web系统.我们目前正在努力建立一些内部标准,以便在开发休息服务时遵循. 有些查询会返回实体列表,例如我们可以考虑让图像库检索服务：/ gell_all_galeries,返回下一个响应： galleries gal

这是关于服务架构策略的更多问题,我们正在构建基于后端休息服务的大型Web系统.我们目前正在努力建立一些内部标准,以便在开发休息服务时遵循.

有些查询会返回实体列表,例如我们可以考虑让图像库检索服务：/ 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>

第一个问题是下一个：也许我们甚至不应该使用和类型,只使用泛型和所有返回列表对象的资源：

<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/22222"/></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/22222"/>
               <author>
                    <link href="http://mysite/author/22222"/>
               </author>
           </photo>
          <photo>
               <link href="http://mysite/photo/22222"/>
               <author>
                    <link href="http://mysite/author/22222"/>
               </author>
           </photo>
          <photo>
               <link href="http://mysite/photo/33333"/>
               <author>
                    <link href="http://mysite/author/22222"/>
               </author>
           </photo>
          <photo> ..... </photo>
    </photos>
  </gallery>

我的意思是如果我们使用链接而不是完整的对象信息,我们应该去那里多深？我应该在照片中显示作者等等.

可能我的问题含糊不清,但我想要做的是在这种情况下制定一般战略,以便所有团队成员在将来跟进.

解决方法

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

RESTful系统通过仔细使用缓存来实现可伸缩性.设计资源以将内容分解为具有类似数据波动性的块.例如,根据您的方案,您有一个包含照片的图库列表.我的猜测是你不经常添加/删除画廊,但你会定期添加/删除照片.因此,确保您可以获得没有照片信息的画廊列表是有意义的.这样可以轻松缓存该响应.

优化响应的大小对性能很重要,但缓存更为重要.在线上发送0个字节总是更有效.

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

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

创建没有错：

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

您希望使用Web框架,使创建新资源变得非常简单和便宜.资源很少与您的域实体进行一对一映射,因此您可以根据需要随意创建任意数量的资源.

我最后的评论是关于媒体类型的选择.您应该考虑使用像Atom这样的服务. Atom非常适合管理事物列表,它具有处理媒体元素(如照片)的所有机制.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!