REST Support

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

REST Support

Nestor Hernandez
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: REST Support

Rick Grashel
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users