代码之家  ›  专栏  ›  技术社区  ›  MicE

如何映射RESTful Web应用程序中的不同UI视图?

  •  2
  • MicE  · 技术社区  · 15 年前

    我正在设计一个Web应用程序,它将支持标准UI(通过浏览器访问)和RESTfulAPI(基于XML/JSON的Web服务)。用户代理将能够使用 Accept HTTP头。

    RESTful API将使用以下URI结构(例如,对于“项目”资源):

    • GET /article/ -获取文章列表
    • POST /article/ -添加新文章
    • PUT /article/{id} -基于更新现有文章 {id}
    • DELETE /article/{id} -基于删除现有文章 {ID}

    但是,应用程序的UI部分需要支持多个视图,例如:

    • 标准资源视图
    • 用于提交新资源的视图
    • 用于编辑现有资源的视图
    • 用于删除现有资源的视图(即显示删除确认)

    注意后三个视图仍然可以通过 GET ,即使它们是通过重载处理的 POST .


    可能的解决方案:
    在URI中引入其他参数(关键字),这些参数(关键字)将标识各个视图——即,在上面的基础上,应用程序将支持以下URI(但仅限于 Content-Type: text/html ):

    • GET /article/add -显示用于添加新文章的表单(通过 得到 ,通过处理 )
    • GET /article/123 -以“查看”模式显示文章123(通过 得到 )
    • GET /article/123/edit -以“编辑”模式显示文章123(通过 得到 ,通过处理 PUT 过载为 )
    • GET /article/123/delete -显示第123条的“删除”确认(通过 得到 ,通过处理 DELETE 过载为 )

    上面的一个更好的实现可能是将添加/编辑/删除关键字放入一个get参数中-因为它们不会更改我们正在使用的资源,所以最好保持所有关键字的基URI相同。


    我的问题是:
    考虑到每个资源可以有多个视图,您如何将上述URI结构映射到为常规用户提供服务的UI?您是否同意上述可能的解决方案,或者根据您的经验推荐不同的方法?

    注意:我们已经实现了一个由独立的RESTfulAPI和独立的Web应用程序组成的应用程序。我目前正在研究未来项目的选项,在这些项目中,这两个项目将合并在一起(即为了减少开销)。

    2 回复  |  直到 9 年前
        1
  •  5
  •   Mike    15 年前

    在REST术语中,“备用视图”实际上只是简单的旧资源,因为URI是不透明的。通过从一个链接到另一个链接(在本例中,从文章列表到文章,编辑和删除该文章)可以发现关系。这里的关键是,它实际上根本与您的URI结构无关,也就是说,以下内容同样是“正确的”。

    GET /article/123/edit
    GET /article/123;edit
    

    答案真的只是品味问题。如果它们由一个URI标识,因此可以链接到,那么您就做得对。

    你如何映射上面的URI 为常客服务的统计研究所的结构 用户,考虑到 每个资源有几个视图?

    我将以与HTML应用程序完全相同的方式来完成这项工作,即在XML中提供相同的超链接,以便连接/链接资源(视图),以便客户机根据需要在UI中跟踪和呈现。

    例如

    GET /article/foobar
    
    200 OK
    Content-Type: application/mytype+xml
    ....
    <link rel="edit" href="/article/foobar;edit" />
    ....
    

    最后:

    你同意可能的 以上详细的解决方案,或者您愿意 推荐一种不同的方法 根据你的经验?

    我认为您上面的方法是合理的——但是,您应该绝对关注链接关系,而不是URI模式。

    您可以选择保持更大的粒度,并避免为XML驱动的应用程序单独删除(甚至编辑)资源;只需不在XML中链接到这些资源,而是选择在文章资源本身中包含删除/编辑链接和表单-这将与yo一起工作良好。HTML驱动版本的初始建议。

    一般来说,对XML和HTML驱动的应用程序使用相同资源的方法是一种很好的方法。

        2
  •  0
  •   Adrian K    15 年前

    我不知道你为什么要把这两者合并在一起;虽然这个想法似乎很有意义,但我认为这实际上是一个错误的经济。

    视图通常特定于其使用的上下文。有两种不同类型的用户(人员和服务)都使用同一个通道(HTTP),这一事实不应混淆这一点。

    现在让他们分开似乎是额外的工作,但如果4个月后发生了什么事情,那就意味着你需要再次将他们分开。关注点的分离超出了用户界面/逻辑/数据。

    只要你的逻辑是集中的,并且是有凝聚力的,那么拥有两套观点在我的书中就不是问题。

    作为一种折衷办法,您是否可以为两个视图保留相同的URL结构,但重复(即:一致)?