Expose webservice directly to webclients or keep a thin server-side script layer in between?

Question

Hi,

I'm developing a REST webservice (Java, Jersey). The people I'm doing this for want to directly access the webservice via Javascript. Some instinct tells me this is not a good idea, but I cannot really explain that instinct. My natural approach would have been to have the webservice do the real logic and database access, but also have some (relatively thin) server-side script layer (e.g. in PHP). Clients would talk to the PHP layer which in turn would talk to the webservice. (The webservice would be pretty local to the apache/PHP server and implicitly trust calls from the script layer. The script layer would take care of session management.) (Btw, I am not talking about just hiding the webservice behind an Apache which simply redirects calls.)

But as I find myself at a lack of words/arguments to explain my instinct, I wonder whether my instinct is right - note that while I have been developing all kinds of software in all kinds of languages and frameworks for like 17 years, this is the first time I develop a webservice.

So my question is basically: what are your opinions? Are there any standard setups? Is my instinct totally wrong? Or partially? ;P

Many thanks,

Max

PS: I might add a few bits of information about the planned usage of the whole application:

• will be accessed by different kinds of users, partly general public, partly privileged
• thus, all major OS/browser combinations can be expected as clients
• however, writing the client is not my responsibility
• will potentially have very high load/traffic
• logic of webservice will later be massively expanded for another product which is basically a superset of the functionality of the current project
• there is a significant likelihood that at some point an API should be exposed which can be used by 3rd party developers - obviously, with some restrictions
• at some point, the public view of the product should become accessible via smartphones, too (in other words, maybe a customized version of the site to adapt to the smaller display and different input methods)

Answer 1

I don't think that accessing a REST webservice directly via e.g. JavaScript is generally a bad idea, because that what the REST architecture is designed for. For your usecase you might have some implications to consider:

• Your webservice will have to take care of user management. Since the REST architecture does not support a server side session state you will have to do authentication and authorization on every request. Users will have to maintain their state on the client side.
• Your webservice implementation will have to take care of issues like caching and load balancing and all the other things you might have assigned to e.g. the PHP "proxy" script

For your requirements:

all major OS/browser combinations can be expected as clients

Since you webservice will only deliver data (e.g. JSON or XML) this should not be a problem. The JavaScript part just has to take care to issue the correct requests.

will potentially have very high load/traffic

If you strictly follow the REST architecture you can make use of http caches. But keep in mind that the stateless nature will always cause more traffic.

logic of webservice will later be massively expanded for another product which is basically a superset of the functionality of the current project

The good thing about open webservices is that you can loosely couple them together.

there is a significant likelihood that at some point an API should be exposed which can be used by 3rd party developers - obviously, with some restrictions

Again, with RESTful webservice you already have an API exposed for developers. It is on your clients to decide if this is a good or a bad thing.

at some point, the public view of the product should become accessible via smartphones

Another pro for making your REST webservice publicly accessible. Most smartphone APIs support HTTP requests, so you will just have to develop the GUI for the specific smarphone platform that makes direct calls to the webservice.