bjansen / gyokuro Goto Github PK

Though not a standard per se, having URIs with required elements as path parameters could allow users to create cleaner APIs.

route("/home")
controller object userController {
    route("/{group}/users/{id}/scores")
    shared void showUserScores(String group, Integer id) {}
}

If one defines a partial path on the controller, the default route ends with a trailing slash:

route("/users")
controller class UserController {

    route("") //and route("/") both map to /users/
    shared void listUsers() {}
}

This might not conform to established conventions. Might an empty route, route("") or route, be treated as the default route and separate from route("/")?

route("/users")
controller class UserController {

    route //maps to /users
    shared void listUsers() {}

    route("/") //maps to /users/
    shared void somethingElse() {}
}

I get multiple errors using 0.2-dev and Ceylon 1.2.2 when applying a method to a route, including: Illegal annotation argument... and Type functions are not supported on the JVM.

Generate REST API documentation from the code, something similar to Swagger JAX-RS extension, but without all their annotations (they have just too many), which is possible in Ceylon, thanks to its great metaprogramming, reified generics and its support of named, optional and default arguments).

It could be another module that inspects the app and generates an HTML report. Something that could be done in a continuous integration server, for example.

Possible API:

ws("/websocket", (channel, message) => "Hello world");

See https://modules.ceylon-lang.org/repo/1/ceylon/net/1.2.0-3/module-doc/api/http/server/websocket/WebSocketEndpoint.type.html
See https://github.com/renatoathaydes/spark-ws

Add support according to the specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Check out the JAX-RS way of doing it: https://docs.jboss.org/resteasy/docs/1.0.2.GA/userguide/html/JAX-RS_Content_Negotiation.html

Guava has a MediaType class that helps a little bit with matching accept headers and routes: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net/MediaType.html

You can copy the MIMEParser from my project if you want (I also copied it, but gave credit to the author - Spark also copied but did not even acknowledge): https://github.com/renatoathaydes/easy-jetty/blob/master/easy-jetty-core/src/main/java/com/athaydes/easyjetty/external/MIMEParse.java

I think object declarations should be able to be controllers as well as classes:

route("/foo")
shared controller object foo
{
    route("/bar")
    shared controller object bar
    {
        route("/baz")
        shared String baz()
        {
            return("Hello, World!");
        }
    }
}

Make it clear that those are supported by the framework!

    route("hello")
    shared String func5(String? optional s1, String s2 = "defaulted") {
        ...
    }

Providing an implementation of TemplateRenderer is helpful, but importing the template library might harm flexibility. Mustache, for example, is at version 0.9.3 for Java 8 and 0.8.18 for Java 7. A user might want the option to choose depending on requirements.

As pointed out by @karimiumar, it could be helpful to have access to the controller instances that are automatically created by gyokuro to do post-instantiation things on them, like injecting dependencies with Spring. This shouldn't be too hard, since the framework is already doing that when it calls router.registerControllerRoute.

The current behavior is to write something like

400 — Bad request

It would be nice to customize that output, either by allowing custom error handlers, or custom error pages.

Something similar to:

void myFilter(Request req, Response resp, Anything(Request, Response) next) {
    doStuffBefore();
    next(req, resp);
    doStuffAfter();
}

value app = Application {
   ...
   filters = [myFilter]
};

An extra filter will automatically be added at the end of the chain to call the handler.

Gyokuro 0.1 requires Ceylon 1.2.0 and will not run on a newer version

This is only useful for RESTful APIs, but is good practice for partial updates instead of using PUT.

The current jsonSerializer was good enough for a PoC, but I think it'd be better if we provided an extension point like we did for template engines:

shared interface Serializer {
    shared formal String serialize(Object o);
    shared formal Type deserialize<Type>(String serialized);
    shared formal [String+] contentTypes;
}

And then provide implementations based on:

• the serialization feature introduced in 1.2 (https://github.com/tombentley/alabama ?)
• Jackson
• Gson
• other non-JSON serializers?

The correct serializer would be picked based on the request's content type.

Also provide a deserializer that reads the body of a request and creates an object that can be passed to handlers:

void handler(serialized MyDomainObject obj) { }

serialized indicates that a deserializer should be used to create the instance. The correct deserializer would be picked based on the request's content type.