The title says it all, one cannot make use of method overloading when working with Endpoints. Not a big deal one might think. Well, as usual, it depends. To me, method overloading is a feature I appreciate, since it allows for a great naming consistency and promotes polymorphism, one of the major deals with OOP. I have yet to find out what the underlying limitation is. In Spring MVC for instance, as long as the associated URL mapping is unique, method overloading isn't much of a trouble. Nevertheless, this post adds a quick example proving the feature remains unsupported.
Say your api sports both parameterised and parameterless method of the same name. Again, both your unit tests and the standard maven build succeed and even the dev server starts up. It's only when you load the dev console in the browser you get the infamous (see my previous post) exception:
java.io.IOException: Failed to retrieve API configs with status: 500
Long story short, method overloading isn't allowed and there doesn't seem to be a way around it. Here is what I wanted to achieve - once again, a slightly modified version of Google's own example:
package com.example.helloworld;
import com.google.api.server.spi.config.Api;
import com.google.api.server.spi.config.ApiMethod;
import com.google.api.server.spi.config.ApiNamespace;
import com.google.api.server.spi.config.Named;
/** An endpoint class we are exposing */
@Api(name = "myApi",
version = "v1",
namespace = @ApiNamespace(ownerDomain = "helloworld.example.com",
ownerName = "helloworld.example.com",
packagePath=""))
public class MyFirstAPI {
/** A simple endpoint method that takes a name and says Hi back */
@ApiMethod(name = "sayHi")
public MyBean sayHi(@Named("name") String name) {
MyBean response = new MyBean();
response.setData("Hi, " + name);
return response;
}
/** A simple endpoint method that takes a name and says Hi to a stranger */
@ApiMethod(name = "sayHiToAStranger")
public MyBean sayHi() {
return sayHi("stranger");
}
}
Note that I added a parameterless version of the sayHi() method. Also notice how the @ApiMethod's name differs - sayHi vs sayHiToAStranger. Having experienced the dreaded HTTP 500 error after deploying the modified code, I reached for the client libs generator to see what the actual problem was. Surprisingly enough the build succeeded. But that was only because it essentially skipped the build process. In reality there was fast failure saying:
mvn appengine:endpoints_get_client_lib
...
Error: myApi.com.example.helloworld.MyFirstAPI: Overloaded methods are not supported.
com.example.helloworld.MyFirstAPI.sayHi has at least one overload:
sayHi and sayHi
That's about it.
This post is part of Google App Engine and Android - Pros and Cons, Challenges