Review full API to see if more parts can be made better with Kotlin magic

[perwendel]

Currently only the route mapping has been thoroughly designed for Kotlin. Some of the other areas should be able to improve. For instance Template view functionality and static files.

If anyone has a proposal for improved API please comment here!

[jackmiras]

Hi @perwendel,
I know that you have asked about other stuff to make Spark more idiomatic for Kotlin coders, and I have a suggestion about the route system from Spark.

By now if I was writing a Java API with Spark I'm ending up with enpoints that looks like this:

    Spark.get("/users", userController::get);
    Spark.post("/users", userController::post);
    Spark.put("/users", userController::put);
    Spark.delete("/users", userController::delete);

Or something like this:

    Spark.get("/users", (request, response) -> {
        // Show something
    });
    
    Spark.post("/users", (request, response) -> {
        // Create something
    });
    
    Spark.put("/users", (request, response) -> {
        // Update something
    });
  
    Spark.delete("/users", (request, response) -> {
        // Annihilate something
    });

In Kotlin those code will look like this:

    Spark.get("/users", { request, response -> userController.get(request, response) })
    Spark.post("/users",{ request, response -> userController.post(request, response) })
    Spark.put("/users", { request, response -> userController.put(request, response) })
    Spark.delete("/users", { request, response -> userController.delete(request, response) })

Or would look like this:

    Spark.get("/users") { request, response ->
        // Show something
    }

    Spark.post("/users") { request, response ->
        // Create something
    }

    Spark.put("/users") { request, response ->
        // Update something
    }

    Spark.delete("/users") { request, response ->
        // Annihilate something
    }

And I will have to write even more code if I wanna to use the path method. But since I do not completely agree with the route system existent in Spark I've wrote a layer that makes the route system more easily to read and wrote to cases when I wanna to pass the execution of an request to another class. With that layer that I wrote I'm able to wrote and maintained my endpoints like the example down below.

If I was writing a Java API with Spark I'm ending up with a code more or less like this:

    route("/users")
        .get(userController::get)
        .post(userController::post)
        .put(userController::put)
        .delete(userController::delete);

And if I wanna use the path method I just have to do this:

    route("/users")
        .post(userController::post)
        .post("/singin", userController::signin)
        .post("/signout", userController::signout);

In Kotlin I get a similar syntax that keeps readability:

    route("/users")
        .get { request, response -> userController.get(request, response) }
        .post { request, response -> userController.post(request, response) }
        .put { request, response -> userController.put(request, response) }
        .delete { request, response -> userController.delete(request, response) }

And if I wanna use the path method I just have to do this:

    route("/users")
        .post { request, response -> userController.post(request, response) }
        .post("/signin", { request, response -> userController.signin(request, response) })
        .post("/signout", { request, response -> userController.signout(request, response) })

In this way I have to write less code, don't have to repeat the route endpoint /users every time and another point is that this layer doesn't interfere in the original route system from Spark. This layer also doesn't handle with the mix in of before() and after() methods inside the path() method but this are features easy to implement.

This is my suggestion to improve Spark... I hope that this brings at least a new perspective about the route system.

[perwendel]

@jackmiras I quickly read your comment on my phone so I might have missed something but have you seen the specific Spark Kotlin API since you reference the Java API (which you btw use "incorrectly" by not statically importing the mapping methods)?

The kotlin specific syntax is as the following example shows:

http.get("/nothing") {
   status(404)
   "Oops, we..."
} 

[jackmiras]

@perwendel Sorry about the delay... Answering your question yes I've seen the specific Spark Kotlin API and I really liked a lot because reminds me the Express route system. But I'm just pointing out another way that the routes could be, and I'm aware that is not up to me to decide how the Spark APIs will look like but since you asked for proposals I was just trying propose something that works great for me in my Kotlin APIs.

[jackmiras]

Hi @perwendel I've been taking a look in to the DSL code and in the Spark core code. And in my analysis in order to implement that syntax that I propose previously and also support the template engines I would have to make some changes in the Routable.java class at the core.

Please let me know if we can discuss this topic in here or if there is another place that you guys judge proper for this kind of discussion, because I believe that I will have to show you some code to justify my changes.

[perwendel]

I'm a bit confused why you are showing examples in Kotlin where the Java API is used?

[jackmiras]

Hy @perwendel I don't remember why exactly I've found the need of change the Routable.java class at that time, after my last comment at August 1º I've code a lot of other micro-services using Spark and I ended up with a code that not require me changing the Routable.java class anymore.

Anyway I don't think it's worth the effort of discussing this topic anymore, at least for me, since the recent tweets shows that development of Kotlin DSL is going to a completely different path than the discution that we had in here. For what I've seen of the new proposals for the Kotlin DSL will solve pretty much of the pains that I have, and also I don't think that the people that already use Spark would adapt to the new form of route that I previously proposed.