@ModelAttribute vs @RequestBody, @ResponseBody

A simple difference between @ModelAttribute and @RequestBody is that the former would look at the QueryString and map it to object fields whereas the latter would look at the Body of the HTTP request.

http://.../?name=Something&age=100
public String doSomething(@ModelAttribute User user) { }

Select allOpen in new window

{ "name": "Something", "age": "100" } in request body
public String doSomething(@RequestBodyUser user) { }

Select allOpen in new window

ResponseBody is simply annotating the returned value as the actual content of the HTTP response. It would be converted into appropriate format like JSon/XML. @ResponseBody will tell the framework to inhibit creation of a View.

Now i understand the difference.

1. Now which one is the best approach ???
2. If both are for same purpose to bind to the bean..which one is the best practice or widely used as standard practice?
3. Does both handles multi-part file and equivalent options with one another ?
4. Does any one of them has lesser capabilities then the other one?
5. Which one is more secured in terms of security ?

1. I would it boils down to the use of GET vs. POST methods and which one is better in the given situation. GET has some length limitations. Also see 4.
2. I suppose one could use both on a single method but not sure.
3. Dont think so.
4. RequestBody would be able to map complex JSON to say objects nested within objects. ModelAttribute I dont think it can do that.
5. Request body can be secured over HTTPS but Query parameters will always be visible.

#3 - Seems this link https://javabeat.net/spring-multipart-file-upload/  says ModelAttribute supports multi-part file. this link https://stackoverflow.com/questions/14615692/how-do-i-upload-stream-large-images-using-spring-3-2-spring-mvc-in-a-restful-way says @RequestBody supports multi-part file..

Not sure why you don't think so. Also not sure about the above limitations of using one another

#4 - Does Query parameters will be always visible even when we have the http method as POST ??

#1 - what is the length limitations for GET vs POST ?

#1 - what is the length limitations for GET vs POST ?

This is implementation specific (each server/browser has its own limit).

#4 - Does Query parameters will be always visible even when we have the http method as POST ??

No. When you send query parameters as POST they are not part of the URL (and therefore they are not visible).

@ModelAttribute and @RequestBody which one uses GET and which one uses POST....Does @ModelAttribute supports both GET and POST ???? Does @RequestBody supports both GET and POST ??

A simple difference between @ModelAttribute and @RequestBody is that the former would look at the QueryString and map it to object fields whereas the latter would look at the Body of the HTTP request.

ModelAttribute -> GET
RequestBody -> POST

As the name implies "RequestBody" supports only Body/POST and ModelAttribute supports only GET

so can we use RequestBody always since it takes care of everything...any drawback in using RequestBody always instead of ModelAttribute..Does RequestBody misses anything or any dis-advantage than ModelAttribute ?

Have you read old comments?

Yes i do. i understand RequestBody will take care of everything of ModelAttribute + Complex Json. I understand requestbody is superior than ModelAttribute. Please correct if i am wrong and let me know if RequestBody lacks things which ModelAttribute doesn't have.

A correction:

"Request body can be secured over HTTPS but Query parameters will always be visible."

is incorrect. Both are safe from eavesdropping when used over HTTPS, i.e. sniffing won't be possible over SSL.

So it means RequestBody can be used instead of ModelAttribute always..Is that right? Because we have all functionality of ModelAttribute in RequestBody..Is that correct?

Thanks a lot for your patience and kind answers

Thank you for accepting. But to be fair I think you should also reward points to user "ambience".

I am not sure about the point system. help me with the link to read.