简短版本：在请求处理程序（rest控制器或过滤器）中，如何得到一个结果，就像对 /bar 在我自己的服务器上（包括它通过过滤器和/或获得正确的rest控制器处理程序），除了没有实际执行tomcat连接器要处理的完整http请求，并且以某种方式绕开它进入“内联”状态，可以这么说吗？
长版本：有一个特定的框架，它有客户端和服务器端，我们用它作为我们想要实现的基础。这个框架使用非常统一的rest模式。例如，ui端调用get /{entity}/submissions 要检索所有提交，请获取 /{entity}/submissions/{submissionId} 要按id检索提交，请发布 /{entity}/submissions 创造新事物等。
在我们编写的服务器上，我们通过使用zuul代理来保持这个基础，zuul代理将请求代理到框架的后端服务器。我们需要做的一件事是添加额外的安全性/可见性措施，我们将其实现为zuul过滤器。例如，用户应该只看到来自他们自己部门的用户列表，因此我们创建了一个zuul过滤器，用于捕获get /user/submissions ，并将其更改为 /user/submissions?userDpt={currentUserDptId} （查询是特定框架的api的一部分，它可以正确地处理它）。起初，这看起来是一个不错的解决方案，它重用了大部分框架，而且也是安全的。
然而，当过滤器实现需要提取额外的信息时，它会变得毛茸茸的。例如，考虑get /document/submissions endpoint，它返回一些文档，假设安全逻辑是，它应该仅限于您自己部门的用户提交的文档。所以步骤是
在self上使用rest模板调用get /user/submissions ，这样就可以由我前面提到的用户过滤器来处理，因此结果是只允许当前用户知道的用户。
使用结果添加额外的查询参数，从而转换get /document/submissions 进入 /document/submissions?userId__in={list of user id's} .
（在本例中，一个用户请求对应于服务器上的两个请求，但实际上，如果需要检查更多的内容，这个数字可能会更大）。
sad部分出现在tomcat连接器的请求处理队列空间不足时（当有足够的并发用户在做某件事时），然后出现死锁。较旧的请求正在等待较新的请求完成，较新的请求正在连接队列中等待较旧的请求得到处理。我希望，有一种简单的方法仍然可以执行相当于self-rest调用的操作（它将通过所有过滤器），但不会以向tomcat连接器发出额外的http请求为代价。这似乎是一个非常奇怪的用例，而且到目前为止我还没有在google上找到解决方案。