Checked the official ref, found a million ways to do things.
I guess I have 2 set of use cases.
1. return customized http response, basically I am responsible for filling in status code, response body(either XML or JSON or text).
2. return Model and View. view is a jsp page typically and fill in the view with data from modle.
My question is which is a better way to go? it possible to mix them together. In my first use set, is it possible to return a View? also is it possible to have both on them in one method. something like if A return customized http response, if B return ModelAndView.
Thanks!
The return value from any request handling method (i.e. on marked with the #RequestMapping annotation must either identify a view (that will generate the HTTP Response) or generate the HTTP Response itself.
Each handler method stands alone; by that I mean, you can return a view name from some handler methods and generate the HTTP Response in other handler methods.
Check out 15.3.2.3 Supported handler method arguments and return types in the Spring 3x reference document at http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
As an option to generating the HTTP Response in the handler method, you could setup multiple view resolvers; one or more for normal view resolution (jsp pages, tiles, etc.) and one or more for "special" view resolution (XML, JSON, etc.). For the "special" views, you may want to create your own view class that extends org.springframework.web.servlet.view.AbstractView.
You can accomplish something similar to what you are describing using the ContentNegotiatingViewResolver, which can deal with serving different content based on a request, with no changes required to your #RequestMapping annotations, or in fact anything in you're controllers.
There are plenty of resources on how to use this method, including this and this
Related
i would like to know what is the benefit of using HttpResponseMessage as the return type in my ApiController ? compare to returning the typed entity or collection directly.
we were trying to decided on a practice to keep things consistent for the project we are working on.
Returning HttpResponseMessage is useful when you are trying to use your controller layer as the translation between the HTTP protocol and your internal .Net services. It allows direct control over the HTTP payload and headers. It makes it easy to return 202, 204, 304, 303 responses. It makes it easy to set caching headers. You have explicit control over the media type of the response.
By returning an object you effectively adding a "do nothing" layer to your architecture. Consider....
public Foo Get(int id) {
return _fooRepository.GetFoo(id)
}
What is the purpose of this method? What value does it add? At least in MVC land, the controller had the role of matching the model and the view.
When you return objects from an APIController you have to impact the HTTPResponseMessage indirectly using a set of abstractions that are specific to Web API/MVC and have no corresponding concept in the HTTP world. Formatters, ActionFilters, ModelBinders, HttpResponseException are all infrastructure designed to allow the framework to process your HTTP request and response messages behind the scenes.
Returning HttpResponseMessage directly requires that your controller method does the work necessary to return the desired HTTP message.
I don't believe that it adds any complexity to your application, it just makes what is happening visible.
It comes down to whether you want to use Web API as an "object remoting over HTTP" framework (in which case I would also take a look at ServiceStack) or whether you want to take advantage of HTTP as an application protocol.
We're building a web api whose GET methods return DTOs. We'd like to build it so that, under certain circumstances, these DTOs are stripped of unnecessary properties in an effort to control the volume of data being sent down to the client. For example, when we return one of our email DTOs we sometimes would like the client to specify that it only needs a subject, date and ID and not the body of the email. In other scenarios, of course, the body of the email is needed.
What's the best way in the MVC WebApi to do this? I've looked into MediaTypeFormatters but they seem focused on the format of the data (JSONP, XML) rather than the content.
It sounds to me like you would like to have a custom mediatype.
This could be used in combination with a custom MediaTypeFormatter.
For instance, you could define your own mediatype (this is a bad example of a name):
application/vnd.me-shortform
And then, in your code you can omit filling in the emailbody and let the default formatter format your result.
Or you could write your own MediaTypeFormatter (subclassing an existing one) and register it for your custom mediatype.
Then, in the MediaTypeFormatter you could either through attributes on your DTO or something similar decide that the email body is not necessary and omit having it as part of the result.
Mark Seeman on Vendor Media Types should give you a good starting point.
I'm designing an application trying to follow the REST spec. I'm trying to figure out the best way to design it.
So let's say I'm doing a POST call that so I have a "post" method in my controller and model
// in controller
function post()
{
//call post model here
}
In my post request I need to make the following checks:
-validate fields
-make sure item name is unique for that user
-make sure there are less than 10 items
-etc (there could be more cases)
Now in controller post function I will return a REST message and status code based on whatever happens, which is fine, but I'm curious to know where it's better to keep all those checks.
I can put all the checks in the model and then return some kind of array like:
array('text' => 'return response text/array or whatever here', 'code' => '200/400/etc')
Then just return this in the controller, or is it better to break up those checks into individual functions within the model and then do all the checks in the controller?
// in controller
function post()
{
//if validation fails -> send response
//if name is not unique -> send response
//etc...
}
From a design point of view, if I ever wanted to potentially call the "post" method in the project model from other methods, it would not have an all encompassing function to handle it, however if I do keep it all in one model function it doesn't give me a lot of reusability. If I had to pick sides, chances are I probably wouldn't need to reuse those "check functions" too much anyway, however it also seems weird to have all that response info in the model rather than the controller.
Can anyone please give me some input on this.
I would not create post method inside the model (although having it in the controller is perfectly fine) simply because you just put code/model in such a frame that is not re-usable plus less readable. For instance, instead of post method in the model I would create create method.
There is no one-fits-all way for data validation. I like creating validation classes which have only one method validate for various data types (e.g. username validation class checks if it matches regex and is unique). It's better than copy pasting the validation code to every action (DRY). Where to call this class method? It depends. You can simply call that it in the action. Since the validation code is inside the validation class, it will look alright. You can also create a mapper which takes the request, determines what validations have to be performed and etc. but it might be overkill and is hard to do properly (maintainability wise).
For output again - DRY. It depends on what MVC framework are you using and there might be a good solution for this already. If not, you can create a class for that (yup, I am DRY maniac). You pass response code, array (or string) with response and class nicely wraps everything into JSON, XML format. Advantages: if you change then output format then you need to change only in one place.
Also consider using Remote Facade pattern.
Hopefully, you found something useful in this post.
I would separate the API from the MVC application and use Apify
I created a custom view that uses Json.Simple to serialize the model and write the JSON to the response directly.
For some requests, I need to send back a static JSON message, so I am wondering can I reuse a View instance I created earlier (with the message already set)?
My View class is thread-safe.
Sure. As long as you make sure it's thread-safe, as you say, there's no reason that your controller can't return the same View object multiple times. Unorthodox, but valid.
I do not see any problem in reusing an already created view since the render method gets current response object.
can any one tell me the difference between request.setAttribute and model.addAttribute in spring web app?
The difference is, that Model is an abstraction. You could use Spring with servlets, portlets or other frontend technologies and Model attributes will always be available in your respective views.
HttpServletRequest on the other hand is an object specific for Servlets. Spring will also make request attributes available in your views, just like model attributes, so from a user perspective there is not much difference.
Another aspect is that models are more lightweight and more convenient to work with (e.g iterating over all attributes in a model map is easier than in a request).
Request V/s Model
where request could get attributes through getAttribute("") method. normally it is used for getting information from defined attributes and used inside the method for performing the different operations. So Basically Request used for input.
Just like Request, the model provides addAttribute("","") method, Through this model, we could make the object and storing data inside model object and deploying it on result Server Page.Basically it used in storing input data which is provide by us and storing for some time.