Servlets vs Beans

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 开发者_如何学Go(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 !

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.

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.

authenticate themselves (this also involves handling account creation)

Servlets have built-in security capabilities as well as several libraries (Spring security, Apache Shiro).

There is no need (for now) for WSDL or other complicated stuff.

WSDL is most commonly used to describe SOAP web service.

Would you use servlets or beans ? - to handle authentication

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.

is going stateful a good idea

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.