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.
Related
Recently I built MEF WCF service, hosted on IIS 8, which receives the command, performs long background process with SAP ECC and Local DB, then returns the status. So user interface input and output is only the string.
In Internet there are many blog post about WCF Dead and that it's better to use WEB API, and in the future ASP.NET Core, which is even better...
My question is, is there the sense to update the project to ASP.Net Web Api or wait to ASP.Net Core, or it's better to use another technics for this type of work?
Having more people talking about a technology does not means another similar one is completely dead; as an example look here to find about incoming WCF implementation for .Net Core.
Of course, this is a subset, as for Web API, MVC or Entity Framework are not uspporting today all features that their Full 4.x versions do.
Short answer: you can keep you WCF implmentation and come back later.
Longuest answer: look at what features WCF for .NET Core contains (especially for bindings) to see if porting would be easy, or if you need alreday to tihnk about moving to something else.
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
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 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.
Basically I need to setup my ASMX file so that when I pull it up in a browser to display the WebMethod specification the Soap Header conforms to this format:
<soap:Header>
<wsse:Security>
<wsse:UsernameToken wsu:Id='SecurityToken-securityToken'>
<wsse:Username>Username</wsse:Username>
<wsse:Password>Password</wsse:Password>
<wsu:Created>Timestamp</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
Back-story: I'm integrating with a client application that is already built (and owned by another company). Basically this client application already has their soap messages all set up from its past integrations with other companies. So we've opted to just build a web service using an ASMX file that matches the WSDL that they're already setup to consume.
Is it possible to get WS-Security working on an ASMX file or is ASMX too simplistic and I have to upgrade to WFC (which I really don't want to do)?
Is it possible to get WS-Security working on an ASMX file or is ASMX too simplistic and I have to upgrade to WFC (which I really don't want to do)?
Yes, it is possible using Web Services Enhancements 3 (an add-on for Visual Studio 2005 and ASMX). See this MSDN page for a WSE-3-specific tutorial and use the usernameOverTransportSecurity assertion, noting that this is not actually secure unless the connection takes place over a protected transport (i.e. SSL).
It is, however, not recommended that you do this, and I cannot fathom why you would not "want" to "upgrade to WCF" given the choice. Please note the following very important limitations of ASMX/WSE:
WSE is no longer a supported product. Although it still works, it no longer receives updates or even bug fixes.
No version of WSE will successfully integrate into Visual Studio 2008, or even Visual Studio 2005 running on Windows Vista x64 or newer.
WCF goes to a lot of trouble to provide thread-safe client operations and allow proxies to exist for long periods of time (which in turn provide significant per-operation performance benefits). WSE proxies, on the other hand, are disposable non-threadsafe objects that incur a setup time with every remote method invocation (even when using Secure Conversation). This also makes them largely unsuitable for Dependency Injection and many other widely-used patterns.
These are just some of the reasons why you shouldn't use WSE anymore. The reasons why you should use WCF on the client side are manifold, including but not limited to separation of the model and proxies, consumption of REST-based services, and better handling of collection types.
Unless you really must continue to use ASMX, please reconsider your refusal to move to WCF - unless the service does a lot of unusual things with XML serialization, it takes no more than 5 minutes to make the switch.
No, legacy ASMX web services do not support WS-Security, or any of the other WS-* standards.
Since Microsoft now considers ASMX web services to be "legacy technology", you should be doing this work using WCF.
Another answer suggests using WSE. This is even less of a solution. WSE is flat-out obsolete, and should only be used as a last resort.
You can implement a SOAP / WS-Security service using classic web services. Here's a tutorial from MSDN.
All of this is easier in WCF though.
EDIT:
Pulled the wrong link. Here's the one I meant to paste (CodeProject tutorial that uses WSE 2, though WSE 3 is the latest release and I have used that exclusively pre-WCF).