I'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
Related
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
I can't find anything on the implementation of service discovery for the ASP.NET Web API. For a new project I need to make a decision between WCF and Web API. The service element will be consumed by a variety of clients, mobile, client-side JavaScript but also an ASP.NET website.
For the website the convenience of being able to generate a client against a WCF service is obviously a plus. I am not that familiar with RESTful web services but I see that there is Web Application Description Language (WADL). Maybe it is my ignorance but surely it is a good thing to be able to advertise the correct way to consume your service?
My main question: is there anything that generates a WADL or similar for WEB API?
Secondary question: this tool looks like it generates a client based on a WADL, is there anything else that makes life easy keeping a client up to date with a RESTful web service?
There is a considerable amount of work going in there. It is not finished but watch the space.
Having a look here (and newer Yao posts):
http://blogs.msdn.com/b/yaohuang1/archive/2012/05/21/asp-net-web-api-generating-a-web-api-help-page-using-apiexplorer.aspx
Also
http://blogs.msdn.com/b/yaohuang1/archive/2012/06/15/using-apiexplorer-to-export-api-information-to-postman-a-chrome-extension-for-testing-web-apis.aspx
I blogged an approach to generating WADL with ASP.NET Web API here: http://blogs.msdn.com/b/stuartleeks/archive/2014/05/20/teaching-asp-net-web-api-to-wadl.aspx
I have an application that I'm building and for the moment, I built some web services using ASMX. In the end, the application will be deployed on azure. The web services are really simple in that all they do is call a class in the AppCode folder that handles all the work.
Is it going to be better/easier/faster/more performant to move my web services to WCF or to Web API?
Thanks for your suggestions.
PS: I want to add that the web services will need to work in HTTPS. At the moment, they're on HTTP because I'm in development mode.
One-liner: if you have already got a working code and it is risky to move it to another technology stay with the working code.
Depends who is answering.
Web API embraces HTTP and gives you flexibilities not possible with ASMX and WCF. If you care about HTTP, content-negotiation, media types and you need your service to be called from any client (including AJAX) then Web API.
If you need to be able to use WS* security standards (e.g. using X509 certificates, ADFS, etc), possibly change your binding, serve to different clients using different bindings, extensibility, etc use WCF.
If you already have a working code, and all you care about is RPC and your clients are always going to use ASMX then stick with ASMX.
Performance
No benchmark but my gut feeling, in descending order: Web API, ASMX, WCF
Easier
In descending order: ASMX (since you know it), Web API, WCF
Faster development
If you know them all, Web API and ASMX then WCF
PS: it is good to pick up new technologies. The way things are going (and since you are already moving to Azure) it is important to invest on new technologies.
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.
I'm wondering how many folks using the Microsoft development stack (IIS and/or ASP.NET) are actually using REST? If so, what forms of rest are being used?
REST can be categorized a zillion ways, but for the purpose of this question I'll categorize it as follows:
Radically REST: Using all the
HTTP methods PUT/POST/GET/DELETE
Moderate REST: Using GET/POST
REST Hybrid: Uses just the GET or
POST HTTP method, but follows
RESTful principles of addressability
and state.
In a class I'm teaching we've been trying to implement a "radically RESTful" service on IIS, but we've been having difficulty implementing the PUT method. There doesn't seem to be a lot of buzz on implementing PUT on IIS so I'm wondering how many people are actually using full blown REST? Are you using REST?
I'm involved in a project that uses WCF REST on IIS, but of course I'd recommend having a look at the framework I built: OpenRasta is a .net open-source stack that makes implementing REST much easier.
Google is your friend. The main site is http://trac.caffeine-it.com/openrasta.
I think part of the reason for the lack of buzz around REST on the IIS stack has been Microsoft's original adoption of SOAP as the way, truth and light when it came to web services - especially with Windows Communication Foundation being heavily SOAP focused.
They went on to release the WCF REST Starter Kit, to follow on from the release of .NET 3.5, and also the ADO.NET data services that are part of .NET 3.5 SP1.
As Magnus points out, Microsoft have since released the ASP.NET Web API which builds on the features of the ASP.NET MVC platform to provide a unified approach to RESTful services on IIS.
ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
The WCF Rest Toolkit mentioned in the answer from "Zhaph - Ben Duguid" is now deprecated.
It has now been replaced with the WCF Web API project.
Edit: Which is now also deprecated and replaced by ASP.NET Web API!
It depends how you approach it.
By default IIS will limit verbs to ASP.NET pages to GET, HEAD, POST and DEBUG. You are, of course, free to tell it to accept PUT as well by editing the handler mapping. Assuming you wanted your own extension you'd do something like
<httpHandlers>
<add path="*.example" type="System.Web.UI.PageHandlerFactory" verb="GET, HEAD, POST, PUT, DELETE, DEBUG"/>
</httpHandlers>
If you want to remap .aspx you, of course, can in much the same way, assuming the server is configured to allow you/
I'm pretty sure the Microsoft ADO.NET Data Services uses RESTful services. It might be worth checking out... aside from being restful, it's a really cool tech.
Here's an extract from a white paper on it:
The goal of Microsoft® ADO.NET Data Services is to enable applications to expose data as a data service that can be consumed by web clients within corporate networks and across the internet. A data service is reachable via regular HTTP requests, using standard HTTP verbs such as GET, POST, PUT and DELETE to perform CRUD operations against the service. The payload format used by the service is controllable by the application, but all options are simple, open formats such as JSON and Atom/APP.
Here's a white paper and it's home page (at least what I think is it's home page)
HTHs,
Charles
What version of IIS? In IIS6 you need to enable WebDAV to enable PUSH requests to get through (no, I don't think that makes much sense either :-)). I don't think that's the case in IIS7 though.
I'm using the .Net class, HttpListener, which is the IIS web server engine(http.sys) without the IIS admin tools. I am handling all of the HTTP verbs. You can add attach the ASP.Net runtime to this if you like, but you don't need to.
In fact in a few cases we implemented a version of PATCH as an experiment. Once you get down to the basics, the verb is simply a string in one of the HTTP headers.
You actually cannot categorize REST in a zillion ways. There are may ways of using HTTP to build distributed applications but there is only one definition of REST.