@Path("/hello")
public class HelloWorld {
@GET
public String get() {
return "Hello World";
}
}
Seems very Sinatra-like to me.I see the term "get" twice. The class name is redundant with the resource path. I suppose not a huge problem because many MVC frameworks require classes, but not even close to Sinatra.
Sinatra:
get '/hi' do
"Hello World!"
endHere is an example in Groovy using JAX-RS:
@Path("/hello")
class HelloWorld {
@GET
def sayHello() {
"Hello, world!"
}
}
Almost as clean. The braces and parens make it a bit uglier; but those are just part of the language. class Hello {
def get() {
"Hello, world!"
}
}
I would prefer to see this and then let someone have a routing config somewhere else if they want to move the /hello endpoint.I've never liked the separate routing config approach. Play Framework uses(d?) it in the 1.x branch and I always found it annoying.
Similarly old-world Servlets were done that way too. You'd put the routing information in an XML file and the container would read it at start up.
Further, not a big fan of annotations. Which is declarative programming for Java. In which case, just use a dynamic programming language.
I am a big fan of stepping thru code with a debugger. Which rules out programming via XML (eg Spring) and annotations.
Also, Python has decorators and Python 3 will soon have function annotations.
You misunderstand. Java breakpoints, yes. Spring breakpoints, no.
To troubleshoot Spring, the best you can do is trace (log) and inspect untyped nested hashmaps.
No thank you.
The IDE can sometimes pre-detect trivial errors. Whoopie.
Python has decorators and Python 3 will soon have function annotations.
My condolences.
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;
}http://www.sparkjava.com/why.html
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.
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.