I also felt that a view resolver might be more appropriate than an aspect. I chose an aspect because it has safe access to the method declaration with its annotations via proceedingjoinpoint. I found that there is no safe way from within a method to get at the method's annotations, so l couldn't build a model with the necessary information. And I don't know the inner workings of the view resolvers so well, so l went down a different path :-) 

What I want to achieve is the following. 
As a programmer who writes a Spring MVC Restful web service:
- I have a method which takes request parameters, either via the uri in a get or via the request body in a post. 
- I want to tell my client which parameters/request body I expect for this resource without out-of-band information. 
- For this purpose I want to create an appropriate form which has the former method's uri as action target. For now I want to return an xhtml form because that is a well-defined standard media type for my purpose. 
- I do not want to give the client a rel with an Uri template containing variables because I don't want to give up the opacity of my Uris. Firstly, because I haven't seen an rfc where a uri template was allowed in a rel - rels are for uris, not for templates. Secondly, with a Uri template alone, the client lacks: knowledge of the variable type, knowledge of the appropriate http method, knowledge of default values, and I can't ask the client to pass a hidden field where the client tracks the application status. I could use a custom rel which could be dereferenced to a documentation page where I describe all this, possibly in some machine readable document. Note that I'm not against Uri templates for the client, but there seem to be no accepted standards yet how I can tell the client what to do with a Uri template. I am deep in the field of custom media types and schema definitions. Not so with forms, especially html5 forms. 
- Building the form manually is possible, but error-prone. What if the action uri changes, what if the http method changes? I would have to keep my form in sync manually. Spring MVC has all this information, so why not extract it and build the form automatically? 
- I want to be able to write a minimal method that automatically produces the correct form for a different method which handles the form action. 

I am totally open for suggestions how best to achieve this with spring mvc and jax-rs. 

As a client programmer, I need to be able to follow rels and submit forms. I would like to use a client framework which does this for me properly. See my rest-client sample project for an example. 

I hope I don't tell you stuff you already know and agree with. My impression was, I could not quite convince you why the heck I think it is a good idea to start fiddling with forms in a REST service :-) 

Please let me know if I got your question right. 

Best regards 
Dietrich 




Ricardo Gladwell <notifications@github.com> schrieb:

In src/main/java/org/springframework/hateoas/mvc/FormBuilderAspect.java:

> +import org.aspectj.lang.ProceedingJoinPoint; > +import org.aspectj.lang.annotation.Around; > +import org.aspectj.lang.annotation.Aspect; > +import org.aspectj.lang.annotation.Pointcut; > +import org.aspectj.lang.reflect.MethodSignature; > +import org.springframework.core.annotation.AnnotationUtils; > +import org.springframework.http.HttpEntity; > +import org.springframework.http.HttpHeaders; > +import org.springframework.stereotype.Component; > +import org.springframework.web.bind.annotation.RequestMapping; > +import org.springframework.web.bind.annotation.RequestMethod; > +import org.springframework.web.bind.annotation.RequestParam; > + > +@Component > +@Aspect > +public class FormBuilderAspect { 

I understand that HTML/XHTML is a valid response format from a RESTful web service, I'm just not sure I understand why you need an aspect to do this and why you don't, for example, create a HTML equivalent of the MappingJacksonJsonView?

Also how does the above aspect fit into your typical Spring MVC Restful web service?

None of this is clear from the code you submitted.

Lastly, FormBuilderAspect doesn't have any unit tests.

—
Reply to this email directly or view it on GitHub.