Google App Engine Servlet Design

Question

I have built a server on GAE that handles 6 different types requests over HTTP POST, all of which involve either creating, updating, or deleting objects from the datastore. What is the best design for this? I will tell you my current design and express a couple others.

1. My current design has all requests sent to the same servlet, and uses an "action" parameter as part of the POST to distinguish and handle the different requests. Code the server should run is included here.

e.g.

  public void doPost(HttpServletRequest request, HttpServletResponse response) {
        if (request.getParameter("action").equals("action_1")) {..code..}
        if (request.getParameter("action").equals("action_2")) {..code..}
        .
        .
        .
        if (request.getParameter("action").equals("action_n")) {..code..}
  }

2._Similar to above, but instead of the code here, this servlet just acts as a centralized servlet and calls a dedicated servlet for that action.

3._Have just a dedicated servlet for each action.

What are the pros and cons to the above designs and what is the preferred way to setup a server on GAE? Does accessing the datastore have an impact on my design?

Answer 1

I am in a similar situation. I started out with your option 1, which works fine. The only problem is it requires a lot of argument parsing, converting strings to integers and whatnot, as well as a manual mapping of command names to methods. Options 2 and 3 are equally laborious, but even worse because you have to create a bunch of auxiliary methods. If I had to do it all over again I would use a library that does all that work for me, like this one (I am in fact considering converting to this): http://code.google.com/p/json-rpc/. Voila, no argument parsing or manual creation of helper classes! This one happens to implement a json rpc client-server interface which is good if you are doing an ajax "thick client." If you are generating most of your HTML on the server side you might want another solution.