Servlet 与 Bean
我需要经验丰富的开发人员就项目的软件架构提供建议。
需要为 API 提供 REST 接口，以便客户可以： 1）验证自己的身份（这还涉及处理帐户创建） 2) 对资源发出 get/add/update/delete() 请求（例如存储新书描述 [标题+作者..]）
（目前）不需要 WSDL 或其他复杂的东西。我想说，如果可能的话，我宁愿避免使用 WSDL，因为我肯定不会使用它。这不会用于网站，仅 API 直接使用。
我读过很多东西，但需要以下方面的明确状态： - 您会使用servlet 还是bean？ - 为了处理身份验证，有状态是一个好主意吗？处理会话的最佳且简单的方法是什么？
我正在寻找最简单的方法，因为目前我对 J2EE 的了解还很低。
感谢您的宝贵时间！
I need advice from experienced developers regarding the software architecture of a project.
The need is to provide with a REST interface for an API so that a customer can :
1) authenticate themselves (this also involves handling account creation)
2) Issue get/add/update/delete() requests on resources (for example store a new book description [title+author..])
There is no need (for now) for WSDL or other complicated stuff. I'd say I prefer to avoid WSDL if possible, since I wont definitely use it. This won't be used for a website, only API direct use.
I've read many things but need a clear status on the following :
- Would you use servlets or beans ?
- to handle authentication, is going stateful a good idea ? What's the best and simple way to handle sessions ?
I'm looking for the easiest way to go, since my knowledge of J2EE is quite low at the moment.
Thanks for your time !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果客户要使用 Web 界面访问您的站点，那么基于会话的系统是更好的方法。如果它只是程序使用的服务 api，那么使用 HTTP 身份验证。
如果您想要使用服务 api，那么最好的选择可能是查看 JAX-RS 等 RESTy 框架之一。您可以将其用于实际网站，但通常不会以这种方式使用（因此示例与域并不真正匹配）。
如果您正在创建一个网站，那么请考虑使用 Stripes 或 Struts 2 等操作框架之一。这些框架允许您绑定到 RESTy URL，但它们也非常适合创建网站。
对于其中任何一个，最好对 Servlet 有一个基本的了解，特别是 HTTP、工作流程、重定向和转发之间的差异等，因为这些框架利用基本的 Servlet 模型。
所有这些都可以使用原始 Servlet 轻松完成，框架使事情变得更容易，并且 JAX-RS 和 Stripes/Struts 2 的启动影响相当低。
If the clients are going to be using a Web interface to get to your site, than a session based system is a better way to go. If it's just going to be a service api used by programs, then use HTTP Authentication.
If you're going for a service api, you would likely be best served by looking at one of the RESTy frameworks like JAX-RS. You can use this for an actual website, but it's not typically used that way (so the examples don't really match up to the domain).
If you're doing a website, then look at one of the action frameworks like Stripes or Struts 2. These will allow you to bind to RESTy URLs, but they're also great for doing web sites.
For any of these it would be better to have a base understand of Servlets, notably HTTP, the workflow, differences between redirects and forward, etc. since these frameworks leverage the basic Servlet model.
All of this can be done readily with raw Servlets, the frameworks just make things easier, and both the JAX-RS and Stripes/Struts 2 are pretty low impact to get going.
一言以蔽之？两个都。您想要 servlet 和基于 POJO 接口的 bean，但不想做同样的事情。
如果您想要 REST，您将使用 servlet。这些是Java EE中的HTTP监听器，而REST是基于HTTP的。
话虽如此，我建议使用基于接口的 POJO 来实现完成所有工作的代码。它将使您的代码更容易测试和更改。
REST 是众多部署选择中的一种。如果您坚持使用基于接口的 POJO，则只需在 bean 上使用不同的包装即可更改部署策略。
除了身份验证和授权、绑定和验证之外，REST 层不应该执行任何操作。让它听从 POJO bean 来完成工作。
Servlet 通过 URL 重写或 cookie 来处理会话。利用他们给你的东西。
但REST服务应该是无状态的；没有会话，调用之间没有保存状态。
您可以在拨打电话之前使用过滤器检查身份验证。就是这样交叉的。将过滤器视为 HTTP 的方面。
In a word? Both. You want both servlets and POJO interface-based beans, but not to do the same thing.
If you want REST, you'll use servlets. Those are the HTTP listeners in Java EE, and REST is based on HTTP.
With that said, I'd recommend using interface-based POJOs to implement the code that does all the work. It'll make your code easier to test and change.
REST is one deployment choice among many. If you stick with interface-based POJOs, you'll be able to change deployment strategy simply by using a different wrapping on the bean.
The REST layer should do nothing besides authentication and authorization, binding and validation. Let it defer to the POJO bean to get the work done.
Servlets handle sessions either with URL rewriting or cookies. Leverage what they give you.
But REST services should be stateless; no sessions, no state saved between calls.
You can use a Filter to check authentication before making the call. It's cross-cutting that way. Think of Filters as aspects for HTTP.
Servlet 具有内置的安全功能以及多个库（Spring security、Apache Shiro）。
WSDL 最常用于描述 SOAP Web 服务。
您是说企业 Java bean 吗？它们不会帮助您，您仍然需要一些东西来处理 HTTP 请求 - servlet 就可以发挥作用。但您可能希望有一些东西来实现实际的业务逻辑 - servlet 只是网关，不要在那里实现逻辑。
从技术上讲，您可以通过 SOAP 公开 EJB（但您需要 REST）或使用 JAX-RS（Java EE 堆栈的一部分），但显然它在底层使用 servlet。
原则上 - REST 是无状态的，没有会话状态。然而，对每个请求进行身份验证可能会花费太多。因此，您将在 HTTP 会话结束时（使用 servlet 轻松处理）至少存储 JSESSIONID。
Servlets have built-in security capabilities as well as several libraries (Spring security, Apache Shiro).
WSDL is most commonly used to describe SOAP web service.
You mean enterprise Java beans? They won't help you, you still need something to handle HTTP requests - where servlets come into play. But you will probably like to have something to implement the actual business logic - servlets are only gateway, don't implement logic there.
Technically you can expose EJB via SOAP (but you wanted REST) or use JAX-RS (part of Java EE stack), but obviously it uses servlets underneath.
In principle - REST is stateless, there is no conversational state. However authenticating on every request might cost too much. So you will at the end HTTP sessions (handled easily with servlets) at least to store JSESSIONID.