设计相关查询以在 Spring 3 中实现 Restful 应用程序
我已经有一个在 Spring MVC 3.0 中实现的应用程序。现在我想将此应用程序转换为一个安静的应用程序，以便业务逻辑保留在一个应用程序中，而 Web 层保留在另一个应用程序中。
现在，为了使用 Rest 实现此目的，我的 Web 层将充当休息客户端，它将访问业务逻辑实现相关应用程序公开的服务。
我感到困惑的一点是我应该如何为此实现登录。
我是否应该在休息后请求中将登录凭据从Web应用程序发送到服务应用程序，然后维护充当jsessionid的id来授权我的进一步请求
或者我应该对每个请求进行身份验证和授权
还是已经提出了任何设计模式通过Spring来实现这种需求。
有这方面知识的人可以帮助我吗？
I already have an application implemented in Spring MVC 3.0. Now i want to convert this application into a restful application in such a way that bussiness logic remains in one application and web layer remains in another application.
Now to achieve this using Rest my web layer will act as a rest client which will access the services exposed by the business logic implementation related application
The point where i am confused is how should i implement login for this.
Should i send the login credentials from the web application to the service application in a rest post request and then maintain the id that would act as a jsessionid authorizing my further requests
Or should i authenticate and authorize every request
Or is there any design pattern already proposed by Spring for achieving this kind of requirement.
Can anyone having knowledge about this help me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该对 REST Web 层和“普通”/客户端 Web 层都具有身份验证。考虑这个问题的最简单方法是忽略这样一个事实：在您当前的情况下，您将同时编写 REST API 的客户端和服务端。相反，请考虑客户端连接来自外部源。
这应该清楚地表明 REST 服务需要对所有请求进行身份验证。通常，您将使用 HTTP Basic Auth 单独验证每个请求；如果数据敏感或由于其他原因需要保护凭据，您可以使用 SSL。从哪里获取这些凭据可能是特定于应用程序的。
拥有某种 API 密钥是一种常见模式，客户端将使用该密钥对自身进行身份验证，但 API 无法单独识别客户端的用户。您还可以实现一种直通身份验证，只要您的 API 了解有关这些用户的信息，客户端用户的凭据就会随每个请求发送到 API。在这种情况下，您的用户可以使用客户端（您已经实现的 Web 应用程序）或直接使用 API。
You should have auth on both the REST web layer and the 'normal'/client web layer. The easiest way to think about this is to ignore the fact that in your current situation you will be writing both the client and service side of the REST API. Instead, consider the client connections to be coming from an external source.
This should make it clear that the REST service needs to authenticate all requests. Generally, you'll authenticate each request separately with HTTP Basic Auth; if the data is sensitive or the credentials need to be protected for some other reason, you can use SSL. From where you get these credentials is probably application-specific.
It's a common pattern to have an API key of some kind, where the client will authenticate itself with the key but users of the client are not known individually by the API. You could also implement a sort of pass-through auth, where the client user's credentials are sent with each request to the API, so long as your API knows something about these users. In this case, your users could either use the client (your already-implemented webapp) or directly use the API.