You're missing out on all the power that jax-rs gives you though with how it binds to things like jackson.
eg:
@Path("/companies")
public class CompanyResource {
@GET
@Path("/{id}")
@Produces(MediaType.APPLICATION_JSON)
public Company getFromDB(@PathParam("id") String companyId) {
return SomeDatabase.get(companyId);
}
}
public class Company {
List<Person> employees;
}
public class Employee {
String name;
int age;
Employee manager;
}
You start to understand how good jax-rs and modern Java can be when you actually start using it for something useful.
get(new JsonTransformer("/companies/:id") {
@Override
public Company handle(Request request, Response response) {
return SomeDatabase.get(request.params(":id"));
}
});
public class Company {
List<Person> employees;
}
public class Employee {
String name;
int age;
Employee manager;
}
So it's got the same functionality as the industry accepted standard, same concision as the industry accepted standard, only the syntax is different. Why not just use the industry accepted standard syntax, then? Why isn't Spark a JAX-RS implementation?
I haven't written Java in a while and I've never seen any other examples of JAX-RS, so feel free to take this with a grain of salt. That said, in my opinion JAX-RS looks uglier, less clear, and more verbose than Spark, and I'd want an alternative to JAX-RS were I ever to write Java web code.
I have done JAX-RS, for small web apps where you aren't trying to build in the kitchen sink, Spark is looking nice. Spark doesn't seem to be trying to replace JAX-RS, it seems to just be making the syntax a bit easier and doing lightweight REST in a way I find unique and really applicable to small web apps. He uses plain Java main.
You can use a plain Java main with JAX-RS, too (when using an embedded server like, say, Jetty – just like Spark). Dropwizard does exactly that.
Well, I don't know... I'm sure Spark is great, but dropping a widely accepted, well established and quite liked standard just for an arguably "bit easier" syntax (especially when there haven't been any major complaints about the standard syntax) seems like the wrong tradeoff. I would have loved a JAX-RS implementation with other compelling features like performance, monitoring etc. Another good JAX-RS implementation is always welcome.
eg:
You start to understand how good jax-rs and modern Java can be when you actually start using it for something useful.