我正在设计一个Web应用程序,它将支持标准UI(通过浏览器访问)和RESTful API(基于XML / JSON的Web服务)。用户代理将能够通过使用Accept
HTTP标头中的不同值来区分这些。
RESTful API将使用以下URI结构(“article”资源的示例):
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
获取,通过POST
处理)GET /article/123
- 以“查看”模式显示文章123(通过GET
提取)GET /article/123/edit
- 以“修改”模式显示文章123(通过GET
获取,通过PUT
处理,重载为POST
)GET /article/123/delete
- 显示第123条的“删除”确认(通过GET
提取,通过DELETE
处理重载为POST
)上述更好的实现可能是将add / edit / delete关键字放入GET参数中 - 因为它们不会更改我们正在使用的资源,所以最好保持基本URI相同他们。
我的问题是:
考虑到每个资源可以有多个视图,请问如何将上述URI结构映射到提供给普通用户的UI?您是否同意上述可能的解决方案,或者您是否会根据您的经验推荐不同的方法?
注意:我们已经实现了一个由独立的RESTful API和独立的Web应用程序组成的应用程序。我目前正在研究未来项目的选项,这两个项目将合并在一起(即为了减少开销)。
答案 0 :(得分:5)
在REST术语中 - “备用视图”实际上只是普通的旧资源,因为URI是不透明的。通过以下链接发现关系 - 在这种情况下;从文章列表到文章,编辑和删除该文章。这里的关键是它实际上与你的URI结构无关,即以下同样是“正确的”:
GET /article/123/edit
GET /article/123;edit
答案真的只是品味问题。如果它们由URI标识,因此可以链接到,那么您就是在做正确的事。
您将如何映射上述URI UI的结构服务于常规 用户,考虑到可以 每个资源有几个视图?
我会以与HTML应用程序工作方式完全相同的方式执行此操作 - 即通过在XML中提供相同的超链接,以便连接/链接资源(视图),以便客户端在必要时在UI中进行跟踪和呈现
e.g。
GET /article/foobar
200 OK
Content-Type: application/mytype+xml
....
<link rel="edit" href="/article/foobar;edit" />
....
最后:
你同意可能吗? 上面详述的解决方案,或者你会 建议采用不同的方法 你的经历?
我认为您的上述方法是合理的 - 但是,您应该专注于链接关系而不是URI模式。
您可以选择保持“更大粒度”,并避免为XML驱动的应用程序单独删除(甚至编辑)资源;只是不在XML中链接它们,而是选择在文章资源本身中包含删除/编辑链接和表单 - 这可以与HTML驱动版本的初始提议一起使用。
总的来说,为XML和HTML驱动的应用程序使用相同资源的方法是一个很好的方法。
答案 1 :(得分:0)
我不确定我明白为什么要将两者合并在一起;虽然这个想法似乎有道理但我认为这实际上是一个虚假的经济。
视图通常特定于其使用的上下文。您有两种不同类型的用户(人员和服务)使用相同的通道(HTTP)的事实不应该混淆。
让他们分开可能看起来像是额外的工作,但是当4个月内发生某些事情意味着你需要再将它们分开时,它会更加有效。问题的解除超出了UI /逻辑/数据。
只要你的逻辑保持集中,并且具有凝聚力,那么拥有两组视图在我的书中不是问题。
作为妥协,您是否可以为两个视图保留相同的URL结构,但是重复(即:一致)?