Nestor / Group, Definitely awesome feedback. A few things here:
1) There is already support for @GET, @POST, @DELETE, @PUT, @HEAD annotations as well as simply using get(), head(), put() et cetera. There is a cascading order of precedence. So if you have an event method called "createCustomer" and have it annotated with a @PUT, then it will only be accessible using a PUT method. I just haven't written the documentation for this, yet. 2) I definitely agree there needs to be a way to customize error returns. ValidationErrorHandlers still work, but it definitely gets hijacked by RestActionBeans. Different client side frameworks definitely want their errors to be returned in certain ways. 3) I also agree we need a way to modify header fields in responses. JsonResolution would probably be a great place for this to happen. 4) There are already at least two places I know of where HTTP status codes are represented in the JDK (HttpServletResponse is one of them). It probably is better to use those than to create a completely duplicated set. Keeping Stripes as thin as possible. Although, I definitely think JsonResolution needs an ability to set a status code on it. 5) Yes, Jackson is being included directly for now. There was another request to make this pluggable. In IRC, we talked about this and decided it is best left for a future release or if someone wants to contribute it. 6) Easy enough to change the name of HttpRequestMethod. :-) Thanks for the great feedback! -- Rick On Sun, Dec 13, 2015 at 7:08 PM, Nestor Hernandez <ilu...@gmail.com> wrote: > Hi Stripes users. I've checking out the REST support in Stripes. I see > that there are some things missing or to improve: > > - REST support uses naming patterns which is discouraged because > typographical > errors may result in silent failures and other points described by Bloch > ( > > http://jtechies.blogspot.pe/2012/07/item-35-prefer-annotations-to-naming.html). > Now we have annotations. Look at JUnit, they are no more using naming > patterns to test classes, they have @Test. Naming patterns seems like > we're back in Java 1.4. Please let's use @POST, @GET, @DELETE,etc. > - > - REST support by default, and with no chance for further > customization, packages up all the validation errors in a defined way. It > will be better if we leave the developer free to change it respecting > ValidationErrorHandler. Look line 357 of DispatcherHelper. > - > - REST support doesn't have an expressive way to return headers or > error codes. It will be nice if we create a class called HttpResolution > which can send headers, error codes, check ResponseEntity of Spring MVC or > DefaultHttpHeaders of Struts2. > - > - We need an enumeration for status codes something like HttpStatus of > Spring MVC: > > https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/HttpStatus.html > - > - The new class JsonResolution is tightly coupled with Jackson because > JsonBuilder uses Jackson directly. What if need Gson? We need a > JsonBuilderFactory there. > - > - Last, the new class HttpRequestMethod can be better called > HttpMethod, is more shorter. > > Thanks! > > > >
------------------------------------------------------------------------------
_______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
