The main issue I had with spark was, from what I could see, the lack of good JSON support. A major part of grumpyrest is its JSON serialization/deserialization framework (it's roughly half of the whole codebase!) which applies the same principles as grumpyrest does for REST, to JSON. (I even called it grumpyjson in anticipation that I might one day break this out as a standalone project).
Now don't get me wrong, I consider Jackson a high-quality framework, and I like very much how its author takes care of even the smallest details. It's not at all like Spring. However, in making it work as I wanted there were too many things that I could not solve to my satisfaction -- I could not abstract them in a way that was truly re-usable, and every API method would have to deal with these things again. This was even more true for Gson. So in the end, I used them (Gson, to be precise) as a low-level JSON library that basically translates between a JSON AST and serialized JSON, and did the high-level mapping to application classes myself.
public SomeService() {
Spark.post("some/endpoint", this::someEndpoint, gson::toJson);
Spark.get("another/endpoint/:id". this::anotherEndpoint, gson::toJson);
//...
}
private ResponseType someEndpoint(Request request, Response response) {
Something some = gson.fromJson(request.body(), Something.class);
return new ResponseType(some.a, logic(some));
}
private ResponseType2 anotherEndpoint(Request request, Response response) {
return new ResponseType2(otherLogic(request.param("id"));
}
Like yeah I guess it could be have more well integrated json support, but it's not like this is heavy in boilerplate, and I do think it balances the need to occasionally access more low-level aspects of the HTTP stack well.Not to detract from your project, of course.
[0] — https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...