We Keep Coding

Google App Cloud Endpoint API for Stateless Backend App

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

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

Google App Engine class on client side

I am developing an Android app using GAE on Eclipse.
On one of the EndPoint classes I have a method which returns a "Bla"-type object:
public Bla foo()
{
return new Bla();
}
This "Bla" object holds a "Bla2"-type object:
public class Bla {
private Bla2 bla = new Bla2();
public Bla2 getBla() {
return bla;
}
public void setBla(Bla2 bla) {
this.bla = bla;
}
}
Now, my problem is I cant access the "Bla2" class from the client side. (Even the method "getBla()" doesn't exist)
I managed to trick it by creating a second method on the EndPoint class which return a "Bla2" object:
public Bla2 foo2()
{
return new Bla2();
}
Now I can use the "Bla2" class on the client side, but the "Bla.getBla()" method still doesn't exit. Is there a right way to do it?

This isn't the 'right' way, but keep in mind that just because you are using endpoints, you don't have to stick to the endpoints way of doing things for all of your entities.
Like you, I'm using GAE/J and cloud endpoints and have an ANdroid client. It's great running Java on both the client and the server because I can share code between all my projects.
Some of my entities are communicated and shared the normal 'endpoints way', as you are doing. But for other entities I still use JSON, but just stick them in a string, send them through a generic endpoint, and deserialize them on the other side, which is easy because the entity class is in the shared code.
This allows me to send 50 different entity types through a single endpoint, and it makes it easy for me to customize the JSON serializing/deserializing for those entities.
Of course, this solution gets you in trouble if decide to add an iOS or Web (unless you use GWT) client, but maybe that isn't important to you.
(edit - added some impl. detail)
Serializing your java objects (or entities) to/from JSON is very easy, but the details depend on the JSON library you use. Endpoints can use either Jackson or GSON on the client. But for my own JSON'ing I used json.org which is built-into Android and was easy to download and add to my GAE project.
Here's a tutorial that someone just published:
http://www.survivingwithandroid.com/2013/10/android-json-tutorial-create-and-parse.html
Then I added an endpoint like this:
#ApiMethod(name = "sendData")
public void sendData( #Named("clientId") String clientId, String jsonObject )
(or something with a class that includes a List of String's so you can send multiple entities in one request.)
And put an element into your JSON which tells the server which entity the JSON should be de serialized into.

Try using #ApiResourceProperty on the field.

Should a dto implement an associated interface?

Should a bean dto always have an associated interface ?
Below dto is used by jackson to send json over the wire :
public class Bean {
private String date;
public Bean(String date)
{
this.link = date;
}
public String getDate() {
return date;
}
}
Should this class always implement an interface to match its structure ?

I wouldn't unless you're using an API or Framework that requires an interface or are writing an API yourself.
Older versions of J2EE (before it became Java EE) required interfaces for enterprise beans, and some other frameworks use an interface to generate a proxy; however that has mostly been replaced by the runtime generation of synthetic proxies. If you start with a well defined class, you can later add an interface you discover a need for one.
Currently one of my tasks is maintaining an existing web application. Essentially everything in it has the Interface + Class pattern, but for no real reason as its all self contained. The extra files for the interfaces just clutter up the workspace and make tracking down the source of the actual code take a couple seconds longer in each case (can't just highlight and press F3 in Eclipse).

Restful architecture issue with (too many) complex objects

Alright, I've been put in charge of both the server and client (used internally) part of this RESTful architecture. (using restlet).
We've got a resource that exposes the Post operation. Here's a simplified version:
public class UserResource {
#Post
public Representation create(UserRegistration registration) {
SomeService.getInstance().createUser(registration);
return new XstreamRepresentation(new RegistrationResponse(registration.getUniqueCode()););
}
For a few months, we've been the only ones using these services, so domain objects were shared across client and server sides... and it's been working just fine.
Now that we have to document these resources and let other clients use them some "issues" have been arising that made me think this API might be a little too complicated.
This Post service, for example.
The internal method accepts complex type UserRegistration
public class UserRegistration implements Serializable {
private Profile profile;
private Boolean someBooleanProperty;
public UserRegistration(Profile profile) {
this(profile, true);
}
public Profile getProfile() {
return profile;
}
public boolean isSomeBooleanProperty() {
return someBooleanProperty;
}
}
which, in turn, uses another complex object (Profile)
public class Profile {
private String nickname;
private String email;
private String password;
private String firstname;
private String lastname;
private Date birthDate;
private String phone;
private Address address;
private GenderType gender;
private String subscriptionSite;
private Date privacyAcceptanceDate;
private Date subscriptionDate;
private String activationCode;
private String socialSecurityNumber;
...
which is using a lot of complex types and so on.
This use of complex types is what really bugs me.
I either don't know how to document this (apart from making a long long list of these complex objects inner properties) or I'm just lost.
My questions are:
Do I have to simplify?
Is this architecture very bad-designed?
Would a few builder methods do the trick?

By sharing domain entity types between the client and the server, you (not saying you specifically) have completely defeated the point of REST. RESTful systems are supposed to share only media types and link relations. Sharing types like you are doing is much easier with SOAP because WSDL allows toolkits to take care of the details of keeping the client and server types in sync.
REST is all about reducing the coupling between client and server to allow them to evolve independently. Obviously, if you have a large set of shared types, that is going to be difficult, which why you currently have this bad feeling.
The solution I have taken to this problem is to define two media types. One is sort of a generic entity data container. Let's call it BusinessDocument, and the other is called BusinessLayout. The client uses the BusinessDocument to retrieve all the data from the server and the BusinessLayout provides "data binding" information so the client knows where in my UI to display the different pieces of business data.
By doing this I am able to build a client that really doesn't understand the specifics of the data it is dealing with, it just knows how to display it on the UI for the user to interact with. By doing this, I am able to use a single media type, to describe hundreds of different business entities.

There's no need to give the java client to external consumers. Your API should be able to answer to any Http client. The fact that there is a java client that shares the object can depend on different factors but should not influence how you expose your REST API to third party consumer.
So I'd suggest to start writing a pure HTTP client, using apache commons HTTP, to see how your REST API behaves.
The fact that the server objects are complex also should not be of any interest of the API. If the old system was designed modeling object around data, which I consider a bad idea, that's something you have to deal with.
From the REST API you always receive just text, XML or JSON, and you have eventually to parse it into your Java Object, if you have for example and ORM + RDBMS backed system. If you could store Json, like on a a document DB, you do not have this problem but, again, this is of no concern of the REST API per se, but you need a layer that transform JSON to Java Object.
Restlet helps you with this, of course such complicated object is not an easy one to be automagically converted.

Send java object to a rest WebService

I'm searching a nice way to send a java object to my rest web service.
It's possible or not ?
For sample I wan't to send an "User" Object to my rest :
public Class User{
private String name;
private String surname;
public getName(){
return name;
}
public setName(String name){
[...]
}
It's possible to generate AUTOMATICALY this kind of Rest ?
www.foo.com/createUser/name="foo"&surname="foo"

I would consider using a JSON representation for this kind of Java objects.
I prefer the Jersey implementation of JAX-RS and it has built-in support for JSON serialization over JAXB.
Hope this helps...

Have a look at Restlet. The tutorial shows you how to get started.
Restlet allows you to use a number of representation formats, including XML and JSON.

It's possible to generate AUTOMATICALY this kind of Rest ?
www.foo.com/createUser/name="foo"&surname="foo"
That's NOT REST. That's RPC.