2 ms·

Thanks for your feedback. I'll take that into account. You are totally right about having to mock RequestCycle, which isn't good. Furthermore, RequestCycle isn

by moring 3y ago

Thanks for your feedback. I'll take that into account. You are totally right about having to mock RequestCycle, which isn't good. Furthermore, RequestCycle isn't really mockable in its current state. I'm planning to solve both problems in a future version by making it mockable, providing standard mock implementations, and removing the dependency on other web objects (such as the servlet API) from code which is just using RequestCycle. The main point behind grumpyrest is that a lot is _not_ "just Java": While the handler method you presented is, the way it is mounted isn't, nor how dependencies are located and injected, nor how the JSON is validated and mapped to objects and back.

chii 3y ago
> the way it is mounted isn't, nor how dependencies are located and injected, nor how the JSON is validated and mapped to objects and back. the point of a framework is to hide some of that from you. The point of abstraction is that you _should not_ have to know how the server mounts the handlers, just that it does and it does it via a contract specified in the documentation.
- yardstick 3y ago
  Should things be abstracted one step further such that the REST endpoint class merely relays the right params to a Service class. So not much to test anyway (I’m not a 100% code coverage person, I test where it makes the most sense). This way your service can be accessed via REST as well as any other type of endpoint if you wanted (gRPC, SOAP, RMI, CORBA, etc). Defeats the point of this project but this approach has saved me a lot of work in the past when switching RPC stacks.
stickfigure 3y ago
> the way it is mounted isn't, nor how dependencies are located and injected, nor how the JSON is validated and mapped to objects and back. These are problems that every web application has to solve. You can use an existing framework or you can write your own. It might seem like there's a "hand-wire everything" option but in any mature system that turns into "write your own framework" as developers get tired of typing the same boilerplate over and over. For example, I can tell you right now that the team is going to get tired of typing `requestCycle.parseBody()` at the top of almost every method. Some clever sod will eventually figure out how to use AOP to make it implicit. Just like JAX-RS.

by moring 3y ago

chii 3y ago

> the way it is mounted isn't, nor how dependencies are located and injected, nor how the JSON is validated and mapped to objects and back. the point of a framework is to hide some of that from you. The point of abstraction is that you _should not_ have to know how the server mounts the handlers, just that it does and it does it via a contract specified in the documentation.

yardstick 3y ago
Should things be abstracted one step further such that the REST endpoint class merely relays the right params to a Service class. So not much to test anyway (I’m not a 100% code coverage person, I test where it makes the most sense). This way your service can be accessed via REST as well as any other type of endpoint if you wanted (gRPC, SOAP, RMI, CORBA, etc). Defeats the point of this project but this approach has saved me a lot of work in the past when switching RPC stacks.

stickfigure 3y ago

> the way it is mounted isn't, nor how dependencies are located and injected, nor how the JSON is validated and mapped to objects and back. These are problems that every web application has to solve. You can use an existing framework or you can write your own. It might seem like there's a "hand-wire everything" option but in any mature system that turns into "write your own framework" as developers get tired of typing the same boilerplate over and over. For example, I can tell you right now that the team is going to get tired of typing `requestCycle.parseBody()` at the top of almost every method. Some clever sod will eventually figure out how to use AOP to make it implicit. Just like JAX-RS.