Question

I was wondering how people with more experience and more complex projects get along with this “uglyness” in the REST Communication. Imagine the following Problem:

We’ll need a fair amount of functionalities for one specific resource within our REST Infrastructure, in my case that’s about 50+ functions that result in different querys and different responses. I tried to think of a meaningful resource-tree and assigned these to methods that will do “stuff”. Afterwards, the Server Resource Class looks like this:

@Path("/thisResource")    
public class SomeResource {

    @GET/POST/PUT/DELETE
    @Path("meaningfulPath")
    public Response resourceFunction1 ( ...lots of Params) {

        ... logic ....

    }

//
// lots of functions ...
//

    @GET/POST/PUT/DELETE
    @Path("meaningfulPath")
    public Response resourceFunctionN ( ...lots of Params) {

    ... logic ....
    }
}

To construct the urls my client will call, I made a little function to prevent Typos and to take better use of Constants

so my Client looks like this:

public class Client() {
    public returnType function1 () {
        client.resource = ResourceClass.build(Constants.Resouce, "meaningfulPath");
        ...
        return response.getEntity(returnType);
    }

}

Now the questions that bothers me is how could I link the client function and the server function better?

The only connection between these two blocks of code is the URL that will be called by the client and mapped by the server, and if even this URL is generated somewhere else, this leads to a lot of confusion.

When one of my colleagues needs to get into this code, he has a hard time figuring out which of the 50+ client functions leads to wich server function. Also it is hard to determine if there are obsolete functions in the code, etc. I guess most of you know about the problems of unclean code better than I do.

How do you deal with this? How would you keep this code clean, maintainable and georgeous?

Answer 1

Normally, this would be addressed by EJB or similar technologies.

Or at least by “real” web services, which would provide at least WSDL and schemas (with kind of mapping to Java interfaces, or “ports”).

But REST communication is very loosely typed and loosely structured.

The only thing I can think of now, is: define a project (let’s call it “Definitions”) which would be referenced (hence known) by client and server. In this project you could define a class with a lot of public static final String, such as:

public static final String SOME_METHOD_NAME = "/someMethodName";
public static final String SOME_OTHER_METHOD_NAME = "/someOtherMethodName";

Note: a static final String can very well be referenced by an annotation (in that case it is considered to be constant by the compiler). So use the “constants” to annotate your @Path, such as:

@Path(Definitions.SOME_METHOD_NAME)

Same for the client:

ResourceClass.build(Constants.Resouce, Definitions.SOME_METHOD_NAME);