REST API:关于使用单独端点或添加RequestParam的建议

时间:2017-09-21 15:26:40

标签: java rest api

我们在Spring中开发了一个java Web应用程序,它是一个REST api,它模拟了一个简单的留言板,目前我遇到了一个问题。

我有几个端点返回我的onjects的几个json表示。 ES:

project/api/sections
project/api/discussions
project/api/posts

我还有一个BaseController,用于基本的CRUD操作;我的所有其他控制器都扩展了这个BaseController

然后我添加了一些搜索讨论的过滤器,我添加了一个端点discussions/search;端点以RequestParams的形式接受几个可选参数,这是控制器方法签名:

@ResponseBody
@RequestMapping(value="/search",method=RequestMethod.GET)
public List<Discussions> findDiscussioniForumEPT(@RequestParam (value = "idSection", required=false) String idSection,
                                                             @RequestParam(value="competenzeArray", required=false) String[] parametersArray,
                                                             @RequestParam(value="flUnreadDiscussions", required=false) boolean flUnreadDiscussions,
                                                             @RequestParam(value="flIncludeArchivedDiscussions", required=false) boolean flIncludeArchivedDiscussions)

最后一个布尔参数的工作原理是根据讨论对象的日期属性过滤或不过滤讨论(存档讨论)

现在必须添加另一个功能,仅搜索已存档的讨论的功能。

我考虑过以

的形式添加另一个端点
project/api/discussions/archived

但这会迫使我在其他端点project/api/discussions/search

上添加其他方法几乎所有参数

另一方面,我可以在搜索端点上添加另一个参数来覆盖这种情况,从而增加了过滤器的复杂性。

有更好的设计方法吗?

1 个答案:

答案 0 :(得分:0)

纯恕我直言: 一般来说,答案有两个不同的方面:

1。语义: 只要功能仍然是“搜索”,但对于新案例“仅存档”,从语义上讲,使用“仅存档”作为另一个参数(例如布尔值为真/假)更有意义

2。现有的应用程序架构:

a。如果您拥有可靠的整体应用程序,并且无意为每个不同的端点(或其子集)运行单独的(微)服务应用程序集,

然后添加另一个参数,而不是另一个端点在语义上和UI代码前瞻性更有意义。只要所有其他情况都具有相同的端点,我想它更容易管理它,而不是添加更多端点来处理它。

b。但如果不同的功能将作为单独的(微)服务运行,那么新端点更可取。

让我们说:

有一个服务应用运行“常规搜索”功能, 当另一个服务应用程序运行“仅存档搜索”功能时。

在这种情况下,您必须拥有不同的端点,因为您不需要做任何事情来将请求路由到正确的端点。它发生在网络层面。

但是,基于请求参数的路由请求需要额外的层,该层必须决定传递请求的位置。

像这样......

PS。但是这里的这类问题,可以打开一个长时间的讨论(基于每个人的意见),虽然这不是我所知道的这个网站的目的......