Support for sub-resources?

[ascertrobw]

Interesting project - and you look to be very active. Consider this a question rather than an issue.

A problem we have with RestyGWT is the lack of support for sub-resources in the DirectRestService model, which is the model that allows a common Java interface between client and server (obviously desirable). It seems that issue may stem from the underlying gwt-jackson lib which also has an issue raised over lack of support for sub-resources.

I see your lib is based around AutoRest which in the docs states support for sub-resources. Does that also mean your approach can support sub-resources? Could be a useful approach for us in the goal to move off GwtRPC if so.

TIA

[mdavis95]

I believe subresources would be supported in the same way they are in autorest. I would be happy to test a trivial example and see if it works if you can give one.

It should be noted that this project is only a few months old and while we plan to actively develop it to support a multi year project, it is very new.

[ascertrobw]

Sounds great. I'm just revisiting our GWT-RPC code, I'll see if I can peel off a really basic sub-resource example over the next few days. It's quite a big deal for us, as sub-resources represent a very useful design pattern where there is a hierarchy to certain data elements

[ascertrobw]

There's a reasonable description and example on sub-resources here:

https://dkbalachandar.wordpress.com/2017/10/10/jax-rs-sub-resources/

In the article example the sub-resource is instantiated in the method which returns it. The Jersey implementation we use on our server side goes one step beyond this and allows you to return a class, which the inner plumbing will instantiate (assumes a no-arg constructor of course!) e.g.

    @Path("envs/{env_name}")
    public Class<EnvResource> getEnv()
    {
        return EnvResource.class;
    }

...

    @Api
    public static class EnvResource 
    {
         @PathParam("env_name") 
        private String envName;    

...

Note that the sub-resource, as well as being automatically instantiated when needed, also gets an instance field automatically containing the env_name path param which went into the getEnv() call. It's really very powerful where you have a solid hierarchical relationship of 1 item -> N children.

In fact, RestyGWT does support this (or so it is claimed). But they only do so in the RestService model. That requires you to have a separate Java interface declared for the client and the server side - with a lot of redundancy. To be fair, this is not much worse than th current GwtRPC need for separate normal and Async callback intefaces, but it's duplication all the same.

The DirectRestService model in RestyGWT is really attractive - it allows a single Java interface with the @post, @path etc annotations. So there is a single common Java interface for the REST API which both the server side implementation code and the client side request/response handling code can use directly. The catch is that this flavour does not allow sub-resources.

[mdavis95]

This is definitely interesting. I would bet that autorest does not support this and simplerest doesnt either. I will consider supporting this however.

[mdavis95]

the example from RestyGWT

public interface LibraryService extends RestService {
    @Path("book/{isbn}")
    public BookService getBook(@PathParam("isbn") String isbn);
}

public interface BookService extends RestService {
    @GET
    @Path("title")
    public void getTitle(MethodCallback<String> callback);

    @PUT
    @Path("title")
    public void setTitle(String newTitle, MethodCallback<Void> callback);
}

[mdavis95]

should be noted that RestyGWT uses generator and is not GWT 3.x ready.

Domino REST is worth looking at for a J2CL / GWT 3.x friendly choice in addition to SimpleRest and AutoREST
https://github.com/DominoKit/domino-rest
https://github.com/intendia-oss/autorest

[ascertrobw]

the example from RestyGWT

public interface LibraryService extends RestService {
    @Path("book/{isbn}")
    public BookService getBook(@PathParam("isbn") String isbn);
}

public interface BookService extends RestService {
    @GET
    @Path("title")
    public void getTitle(MethodCallback<String> callback);

    @PUT
    @Path("title")
    public void setTitle(String newTitle, MethodCallback<Void> callback);
}

Indeed - the key here is though that this is the RestService flavour of RestyGWT. That's fine, in a sense, but it requires duplication of the interface - one for client side, and one for server side. That is not dissimilar in fact to the current GwtRpc where you have duplicate interfaces - the server one being "plain", and the client one having the Async callback params in it. The issue with that duplication in a REST model is it gets deeper than just the method signature, you also have to duplicate annotations too - so the maintenance headache gets worse when an interface changes. RestyGWT has a very nice DirectRestService to avoid this, but that does not then support sub-resources.

[ascertrobw]

should be noted that RestyGWT uses generator and is not GWT 3.x ready.

Domino REST is worth looking at for a J2CL / GWT 3.x friendly choice in addition to SimpleRest and AutoREST
https://github.com/DominoKit/domino-rest
https://github.com/intendia-oss/autorest

Agreed. We're only 2.9 ourselves at present, but at some stage that will be an issue for most GWT users. Domino looks cool, but from what I could see it looked to just be doing the JSON to Java POJO mapping. It did not seem to be doing any of the request/response API cladding. I didn't dig that deep, so I may have got that wrong.

[mdavis95]

domino lets you define the rest services too. it uses java POJOs instead of @jstype like we use which is a minus for us.