3 ms·

So here's the thing about annotation and Jersey, I believe you can annotate the seralization of return type once at the top of your resource class, the rest, li

So here's the thing about annotation and Jersey, I believe you can annotate the seralization of return type once at the top of your resource class, the rest, like http verb, needs to be repeated unless you take the convention one more level up a'la Rails. But that's Rails, a web framework that people said does not fit for microservice. Sinatra is. But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once... Let's take this further: exception mapping to http response code. In JAX RS, you can map application exception to certain WebApplicationException with specific http response code, I believe you have to handle them manually in Sinatra. You would have to catch the exception and convert it to the intended one per method on your controller.

lmm 12y ago
> But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once... I can't speak for Sinatra, but in Spray I'd just write a directive for this - maybe it exists already, but if not, it's a couple of lines - and then I can use it just like any of the built-in directives. And this is a perfect example of why "just code" is so powerful. Jersey is a very well-designed framework and I'm sure you can find examples where the built-in Jersey thing is better than the built-in Spray thing. But no framework is perfect, at some point you find yourself having to extend these things - and in Jersey's case, IIRC once you want to write your own annotation you need a magic .service file containing a class name to use to interpret that annotation. And then the only way to pass dependencies to that processor is by static global variables. Good luck refactoring that, and don't expect to be able to use hot code replace when debugging it. And good luck remembering how the mechanism works in six months' time. "Plain old code" has a lot to recommend it here. > Let's take this further: exception mapping to http response code. In JAX RS, you can map application exception to certain WebApplicationException with specific http response code, I believe you have to handle them manually in Sinatra. Again, trivial in Spray - I do my error-handling with Either and then I have a meta-marshaller that knows what to do with the error case. Better still, error handling isn't a special case - I do exactly the same thing if I have async code in my methods (can JAX-RS handle Futures? Can it handle a different kind of Future from a non-standard third-party library?). I can do exactly the same thing with a database-transaction monad, and then I can have session-in-view but in a principled, safe, zero-magic way. I can do the same thing to e.g. show debug traces if a special header is present - like Jersey's dynamic choice of serialization format that you were so impressed by, but it doesn't have to be built into the framework, it's just code that I can write myself.
- edwinnathaniel 12y ago
  I've been using Jersey since 2010 and I have never need to write my own annotation. Maybe I'm lucky enough that Jersey fills my need perfectly and maybe you're right that once I needed to write my own annotation, I may run into a bit of trouble (though some people do write annotation only to be consumed by reflection, hence bypassing the service file) but I guess... that's like.. what... 1-5% extreme use-cases? Like... LISP macros that makes programmer reached nirvana or something? But in my case, Jersey fills my need without me writing low-level REST code (dealing with exception to HTTP status code, marshalling objects to different formats) embedded in my controller/business logic. > I can do exactly the same thing with a database-transaction monad, and then I can have session-in-view but in a principled, safe, zero-magic way. You sound like programming in another level higher than mine. I applaud that. I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For now, Java seems to fit the bill for pretty much 99% my use-cases and fit my taste as well (less low-level code stuff because it is built-in the framework that is well-architected/well-designed so that I can focus on business logic code).
  - lmm 12y ago
    > You sound like programming in another level higher than mine. I applaud that. I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For now, Java seems to fit the bill for pretty much 99% my use-cases and fit my taste as well (less low-level code stuff because it is built-in the framework that is well-architected/well-designed so that I can focus on business logic code). Sometimes you don't need it, but there are blub-paradox cases as well; I tried to sum up a few of the things I retrospectively recognize I was missing in Java in http://m50d.github.io/2014/05/16/signs-your-java-program.html http://m50d.github.io/2014/05/16/signs-your-java-program.htm... A lot of it is just being able to track things in the type system that you wanted to track in Java anyway, but it seemed too hard. I mean, I've worked in Java codebases where it would have been very nice to see which methods accessed the database as part of their type. I've even seen one that used a kind of Hungarian notation to express this - in fact if I can point to a single place that set me on the road to Scala, it's http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html . Because I read that and then thought: hang on a minute, why not just make whether a String is encoded part of its type-type, the type that's enforced by the compiler?

lmm 12y ago

> But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once... I can't speak for Sinatra, but in Spray I'd just write a directive for this - maybe it exists already, but if not, it's a couple of lines - and then I can use it just like any of the built-in directives. And this is a perfect example of why "just code" is so powerful. Jersey is a very well-designed framework and I'm sure you can find examples where the built-in Jersey thing is better than the built-in Spray thing. But no framework is perfect, at some point you find yourself having to extend these things - and in Jersey's case, IIRC once you want to write your own annotation you need a magic .service file containing a class name to use to interpret that annotation. And then the only way to pass dependencies to that processor is by static global variables. Good luck refactoring that, and don't expect to be able to use hot code replace when debugging it. And good luck remembering how the mechanism works in six months' time. "Plain old code" has a lot to recommend it here. > Let's take this further: exception mapping to http response code. In JAX RS, you can map application exception to certain WebApplicationException with specific http response code, I believe you have to handle them manually in Sinatra. Again, trivial in Spray - I do my error-handling with Either and then I have a meta-marshaller that knows what to do with the error case. Better still, error handling isn't a special case - I do exactly the same thing if I have async code in my methods (can JAX-RS handle Futures? Can it handle a different kind of Future from a non-standard third-party library?). I can do exactly the same thing with a database-transaction monad, and then I can have session-in-view but in a principled, safe, zero-magic way. I can do the same thing to e.g. show debug traces if a special header is present - like Jersey's dynamic choice of serialization format that you were so impressed by, but it doesn't have to be built into the framework, it's just code that I can write myself.

edwinnathaniel 12y ago
I've been using Jersey since 2010 and I have never need to write my own annotation. Maybe I'm lucky enough that Jersey fills my need perfectly and maybe you're right that once I needed to write my own annotation, I may run into a bit of trouble (though some people do write annotation only to be consumed by reflection, hence bypassing the service file) but I guess... that's like.. what... 1-5% extreme use-cases? Like... LISP macros that makes programmer reached nirvana or something? But in my case, Jersey fills my need without me writing low-level REST code (dealing with exception to HTTP status code, marshalling objects to different formats) embedded in my controller/business logic. > I can do exactly the same thing with a database-transaction monad, and then I can have session-in-view but in a principled, safe, zero-magic way. You sound like programming in another level higher than mine. I applaud that. I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For now, Java seems to fit the bill for pretty much 99% my use-cases and fit my taste as well (less low-level code stuff because it is built-in the framework that is well-architected/well-designed so that I can focus on business logic code).
- lmm 12y ago
  > You sound like programming in another level higher than mine. I applaud that. I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For now, Java seems to fit the bill for pretty much 99% my use-cases and fit my taste as well (less low-level code stuff because it is built-in the framework that is well-architected/well-designed so that I can focus on business logic code). Sometimes you don't need it, but there are blub-paradox cases as well; I tried to sum up a few of the things I retrospectively recognize I was missing in Java in http://m50d.github.io/2014/05/16/signs-your-java-program.html http://m50d.github.io/2014/05/16/signs-your-java-program.htm... A lot of it is just being able to track things in the type system that you wanted to track in Java anyway, but it seemed too hard. I mean, I've worked in Java codebases where it would have been very nice to see which methods accessed the database as part of their type. I've even seen one that used a kind of Hungarian notation to express this - in fact if I can point to a single place that set me on the road to Scala, it's http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html . Because I read that and then thought: hang on a minute, why not just make whether a String is encoded part of its type-type, the type that's enforced by the compiler?