I want to develop RestFul web service using Spring. When I googled, I found that it can be done in two ways. One way is to use Spring's own Spring MVC and the other way is to use Jersey (or any other JAX-RS implementation) that provides support for Spring. I would like to know which approach would be better.
There’s something to be said for the cleanliness that is inherent to the JAX-RS spec. Whereas the Spring MVC approach is sufficient, JAX-RS is targeted solely to implementing REST APIs. Spring MVC isn’t built for that purpose alone and personally, I think it shows. Sometimes it can be a bit verbose or confusing.
For example, if you omit a method on a Spring MVC REST controller, Spring MVC happily assumes you want to have this endpoint available for all HTTP methods. For MVC purposes, this might be okay, for REST, this is not. And if you add the method to the #RequestMapping, you suddenly can’t use the terse notation and need to explicitly declare the value parameter on the notation. Same thing with setting explicit MIME types for an endpoint.
At the moment, I haven’t found anything that Spring MVC can do for REST which JAX-RS couldn’t.
P.S. It's the developer's choice. Technically one can build the same web service with both.
Related
I have an application in mind which I want to develop. I am targeting the application for a big user base, consider it as a social app. But I am not
sure whether to write it with Servlets or Spring MVC.
I have a good grip on Servlets, it would be easy for me to develop, but when it comes to Spring I am still novice.
I am not clear what difference would it make if the app is developed on Servlets rather than Spring MVC.
Scalability or some factors like that?
Any advice would be appreciated. Thanks
It might take you some time to learn Spring but..., once you do, it will provide powerful tools to code.
Its always good to go for Spring framework as it provides:
Dependency Injection support
Spring MVC: easy to customize
Data access support
Spring Security
AOP support etc..
Clearly, Spring provides more functionality than servlets. But if your app is very simple enough, you can go for Servlets.
I've been doing some digging in the web but all i find is either incomplete guides to do it by yourself or guides for the first version of MVC.
Is there any framework for getting a RESTful API or not?
And if no, is there anyway to add a global solution for all models (extending the model or routing of MVC it self), because what i've read involves adding the REST logic to each model/ controller of the application (Which don't look like a good solution to adopt REST)
WCF Web API for MVC3
Add WebAPI support to MVC3 application
Both of these should give you an idea of what's involved.
Are you able to start using MVC4?
I have been using asp.net MVC for around 1.5 years, am enjoying its capabilities, and have deployed many successful web applications, but I'm currently reading about the asp.net Web API technology. And, I find the following:
I can implement any functionality that I used to implement using MVC; using the new Web API and in a more lightweight approach.
It is easier to develop web services using the Web API comparing the asp.net MVC.
So, will the asp.net Web API take over asp.net MVC in the future, or each technology will have its own area to grow in, or should we consider using both of them in the same web application?
Besides the #jmoerdyk's answer, I would like to point something out:
The key is to understand the goal of each technology:
Web API.
This will be the new API for creating web services, this is an alternative to traditional XML services and WCF services, so it's worth pointing out first the main difference between WEB API and the rest of the Web service frameworks.
The primary difference between Web API and WCF/ASMX services is that it's not based on SOAP it's based on HTTP Therefore you can take advantage of all the HTTP features like:
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
use of verbs to define the actions (POST, PUT, DELETE..)
it contains a body that can be used to send any kind of content
It uses URIs for identifying both information paths (resources) and actions
That was the main goal of the Web APIs, known back then as the WCF Web APIs: to stop looking at HTTP through the eyes of WCF - as just a transport protocol to pass requests. Rather, it allows us to look at it as the real application-level protocol it is – a rich, interoperable, resource-oriented protocol. The purpose of the Web APIs was to properly use URIs, HTTP headers, and body to create HTTP services for the web, and for everyone else that wished to embrace HTTP as its protocol and lifelong friend.
Take a look to this article for more information: http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
So basically the Web API could actually be compared against WCF or XML Services
If you are wondering what's going to happen with WCF?
So the fact was we had too many options and therefore too much confusion. What were we to do? We merge teams! (Kind of reminds us of the time of LINQ-to-SQL and Entity Framework, WCF and Ado.Net Data Services and other such examples). So the WCF team and the ASP.NET team joined forces and created a new framework focused on the world of REST/Hypermedia/HTTP services for the web world and thus came out the ASP.NET Web APIs.
MVC
Now that you know what's the goal of the Web API, then it should be easier to say why MVC contains additional functionality to render views primarily.
Your concern is based on the fact that WEB API is actually based on MVC, but their goals are different
On the other hand, the ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services
No, they don't really do the same thing.
Web API is really only for generating JSON, XML or other text based responses for implementing REST based APIs. MVC can do that as well, but the new Web API appears to make it easier, particularly with the automatic content type negotiation.
What MVC does that Web API is not intended for is generating full or partial HTML pages with Views and such.
So each one has their own purpose in the ASP.Net framework and not likely to surpass the other.
WebAPI and MVC are two different things, but they both work in the same framework. WebAPI is used for restful services. MVC is used for web pages.
You can create restful services in MVC, with a lot more work than in WebAPI. The reverse is not true. You can't create Web pages in WebAPI. Therefore, your question is fundamentally confused.
They are going to be merged in new versions, technically both works similar, but API don't have views attached so delivers better performance
Or is Rails by itself just good for developing APIs?
It seems that ASP.NET Web API project types have some history intertwined with WCF (as is detailed in this post for example), so maybe it's not applicable to Rails.
UPDATE
To clarify, Microsoft has the ASP.NET MVC framework. Recently, they came out with a framework called ASP.NET Web API. ASP.NET Web API seems to have similarities to ASP.NET MVC, but is specialized and trimmed down for RESTful web services. Is there an equivalent in the Ruby/Rails space?
So, the answer is Yes to both questions. Rails does have an equivalent and its Rails.
ASP.NET Web API looks like at it's heart is just a RESTful router with type negotiation. I could be totally off base here, but from the tutorials I saw that's what it looked like to me.
So yes, from what I can tell, Rails supports most of the things that the Web API was created for. In fact in Rails most of this stuff is forced onto you until you become informed enough to be able to change it (assuming by that point you know better than to actually do that).
But, as far as Web API functionality. That really comes from the ability to support HTTP verbs (GET, POST, PUT, DELETE) which Rails does.
But a source of confusion might be that in Rails the RESTful API is actually the application itself. Meaning you don't need to implement any other libraries, it's just built that way.
Here's a quick example of that I mean
When you hit /users/1 you will get the data associated with that user depending on the format you requested. So if you request JSON the controller returns JSON, HTML you get HTML, XML you get XML, etc. (As long as said format is implemented for that resource)
A good overview of what I'm talking about are in these two sections:
Rails Guides::Controller: Rendering xml and json data
Rails Guides::Routing: Resources on the Web
So you could build a website, API, or both in a Rails app and they would all start the same way.
But from my limited knowledge on the matter, I would say a ASP.NET MVC with ASP.NET Web API program is actually a lot more like a Rails Program than the regular ASP.NET MVC programs that came before them.
Or it's all just a clever ploy to get as many Capital Letters in a title as humanly possible.
Take a look at grape. It is a pure "Rest" HTTP API framework in ruby.
WSO2 looks like a generic web services framework (as opposed to MVC like Rails) I can't vouch for it but it seems to be more a service framework in the style of WCF Web API (service in the generic sense, not just SOAP).
It's difficult to know what you mean by "APIs"... Rails and ASP are used for developing web sites, and WCF is essentially a web service platform. ASP and WCF have little in common, it's just normal for ASP applications to consume WCF services because they all run on the same stack and platform.
I suppose Rails on the Microsoft side would be a combination of ASP.NET MVC, Linq2SQL or EntityFramework and some WCF.
Ok, this isn't a direct answer to your question, however there seems to be some confusion... Microsoft's ASP.NET Web API is specifically a product offering with ASP.NET MVC 4+. It is a RESTful framework. How does it compare to RoR? I don't know having never tried to install RoR on Windows. As with anything else, experiences vary... Requirements vary. Also try to think ourside the language, construct, context, and framework. Is it better for developing API's? If you're using Linux/Unix, the answer is probably a yes. If you're on a Windows server, the question is a bit trickier.
Finally,
Writing in the ASP.NET Web API will have 0% to do with WCF. Perhaps it is implemented as such under the covers, but the ASP.NET Web API is (from what I've seen and done with it) strictly an HTTP bound API, not TCP/Binary/Piped/etc... like WCF. If you're ask
Yes. It's called Grails. It uses spring. There are tons of plugins available for it and it make creating webapps a breeze. Read more about it here.
Does adding a Web Service to my ASP.NET MVC project break the whole concept of MVC?
That Web Service (WCF) depends on the Model layer from my MVC project to communicate with the back-end (so it looks to me like it needs to be part of the MVC solution).
Should I add this to the Controller or Model layer?
It sounds like you should split out your model into its own assembly and reference it from your MVC-application and WCF-application.
YourApp.Data -- Shared model and data access maybe
YourApp.Web -- If you want to share more across your web-apps
YourApp.Web.Mvc
YourApp.Web.WebService
If you want to do WebServices MVC-style maybe you should use MVC to build your own REST-application.
Is there a specific reason you need to add web services to your MVC application? Unless there is a specific reason you should use your controllers in a RESTful manner just as you would a RESTful web service.
Check out this post from Rob Connery for more information:
ASP.Net MVC: Using RESTful architecture
Separating the Model into it's own project is not breaking the "MVC" pattern. First off, it is just that -- a pattern. The intention of the MVC pattern is to clearly delineate between your data, the data handlers, and the presenters and the way you interface between them. The best way to do it is how Seb suggested:
YourApp.Data
YourApp.Web.Mvc
YourApp.Web.WebService
Something that might help you out is the MVC Storefront that Rob Conery put together. Go watch the video's here:
MVC Storefront Video Series
And if you want to look at the actual code in your browser to quickly see how he did it, go here:
MVC Storefront Codeplex Code Browser
I don't think separating the model into it's own assembly has any bearing on whether or not you're using MVC, you still have a model. Where it is is irrelevant surely?
I've had a go at doing this.
See my result at my blog
ps: I don't believe that this will break the MVC concept so long as you think that a web service is the model of a repository because all a web service does is returning a XML dump.
I have added web services to my application and it works well. I don't believe it violates MVC because it is an alternative interface to your model. MVC is not appropriate for web services because web services don't have a view.
Think of web services and databases as one in the same. Under this analogy, I think it makes sense to place your web service ingteractions where you place your database logic.