0
votes

We have a stateless backend Java app running on Google App Engine (GAE). The engine takes in a string-A (json) and returns a different string-B (json).

The examples on the Google Cloud Endpoints are around creating an Entity - to define the CloudEndpoint Class. Most of the examples seems to be tied to the DataStore - a backend DB.

In our case, the data is not persisted and there are no primary keys. We were successful in creating an entity - with Input and Output string as two fields. It worked, however the resp payload also consisted of a copy of input string.

We have a solution using a standard servlet(req. string and a different resp string) using doPost Method.

Any suggestions - for our scenario - is CloudEndPoint necessary and/or if there is an easy way to conduct this within Cloud Endpoint?

Thanks

1

1 Answers

1
votes

There is nothing that forces you to use the datastore. If you don't need it, don't use it.

You can transform from one Pojo into another for example

public class Input {
    public String inputValue;
}

public class Output {
    public String outputValue;
}

@Api(name = "myApi", version = "v1")
public class MyApi {

    @ApiMethod(name = "hello")
    public Output hello(Input input) {
        Output response = new Output();
        response.resultValue = "Hello " + input.inputValue;
        return response;
    }

}

which via APIs explorer (http://localhost:8888/_ah/api/explorer for me) shows that it results in a POST request / response of equivalent JSON objects:

POST http://localhost:8888/_ah/api/myApi/v1/hello
{
 "inputValue": "Hans"
}

which returns

200 OK
{
 "resultValue": "Hello Hans"
}

The big plus of endpoints is that you can write simple Java methods like Output hello(Input input) and use them from auto-generated (Java) client code that does not "see" that those methods are called over HTTP.

You can use them via regular http if you figure out what the URL is but that's not the intended use.

A more generic way to do JSON methods in app-engine would be to use a JAX-RS implementation like Jersey. That way you don't have to have_ah/api/vN/apiname/methodname methods and the restrictions that come with them (like a specific error response in case of exceptions).

Code with JAX-RS would probably look like

@Path("/whatEverILike")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class MyApi {

    @POST
    public Output hello(Input input) {
        Output response = new Output();
        response.resultValue = "Hello " + input.inputValue;
        return response;
    }
}

but it's a little difficult to set such a project up since you'll need a lot of dependencies. For Jersey for example you'll probably want the following 2 including several transitive dependencies:

org.glassfish.jersey.containers:jersey-container-servlet-core:2.22
org.glassfish.jersey.media:jersey-media-json-jackson:2.22

which unfolds into

aopalliance-repackaged-2.4.0-b31.jar  jackson-core-2.5.4.jar                     javassist-3.18.1-GA.jar       jersey-client-2.22.jar                  jersey-media-jaxb-2.22.jar
hk2-api-2.4.0-b31.jar                 jackson-databind-2.5.4.jar                 javax.annotation-api-1.2.jar  jersey-common-2.22.jar                  jersey-media-json-jackson-2.22.jar
hk2-locator-2.4.0-b31.jar             jackson-jaxrs-base-2.5.4.jar               javax.inject-1.jar            jersey-container-servlet-core-2.22.jar  jersey-server-2.22.jar
hk2-utils-2.4.0-b31.jar               jackson-jaxrs-json-provider-2.5.4.jar      javax.inject-2.4.0-b31.jar    jersey-entity-filtering-2.22.jar        osgi-resource-locator-1.0.1.jar
jackson-annotations-2.5.4.jar         jackson-module-jaxb-annotations-2.5.4.jar  javax.ws.rs-api-2.0.1.jar     jersey-guava-2.22.jar                   validation-api-1.1.0.Final.jar