I am a fairly experienced (mid-level) developer that has spent quite a bit of time working on the backend of many web-based projects. Rarely getting into the ui/display aspects. However, I am now a lead on a project that is in the process of taking an api to a service architecture using an asp.net mvc rest architecture. I have not problem doing this and have written many of these services already. however, I find myself wondering about the parts "hidden" by IIS/WAS and MVC.
What I am hoping to find is a good tutorial that explains what happens from the point a web page (or webservice) is requested to the point it is received by the web page or application takes over. I want to know how IIS (or any other webserver) knows what to do with a request. (One thought was a tutorial for developing your own webserver.)
I realize this is probably a large subject that I don't necessarily need to know all of to be an "expert" web developer. However, it certainly can't hurt and I also am experienced enough to separate the wheat from the chaff.
Thanks in advance!
I would recommend you to download and install Fiddler. Then run it and look at all the traffic that's being exchanged over the wire. It will allow you to see the actual HTTP requests and responses and their exact contents. This will allow you to gather deeper understanding at what happens at the lower network levels which is extremely useful to know when developing a web application.
I have already made an HTTP web server using Java only, able to run Java application at server side. I used the HTTP 1.1 specification. But you may find easier to start with a tutorial about HTTP before reading the specification.
If you are developing a RESTful web service and want to learn more about HTTP I strongly suggest reading RESTful Web Services Cookbook: Solutions for Improving Scalability and Simplicity.
Related
I am responsible for developing the software for a printer-like device, for which I am using C#/.Net and WPF. We now have the necessity for making this software network-capable, so that the device can be remote-controlled over a local network.
The idea I currently have, is to be implement some way of calling the API-functions of our software over the network. This could be done by a client-side DLL, which sends the commands for the API and receives their responses as well as any events, that the device-software issues.
To this date I have only worked a little with socket-based communication using TCP/IP, where I explicitly sent strings over the network and received them on the other side. I did this completely synchronously. However for the new implementation I will need asynchronous calls to the API to query state, issue events, etc. and it seems like it would require considerable effort to implement this using socket-based communication (am I wrong?). I will have to avoid too much custom implementation, since I am under a time-constraint for the implementation.
In my search I came accross the possibility of using SOAP in ASP.Net, which from this CodeProject post, seems to be what I am looking for and does not seem to be too complicate to implement. However in my Visual Studio 2015 installation I am unable to find the project-type they are using there, which is a "ASP.Net Web Service".
My question is now:
Given my choice of technologies (.Net), would this be the most effective way for achieving, what I have in mind? Is it still possible to do this in Visual Studio 2015?
Update:
As always I found one of the questions afterwards: Here is an explanation of how to create an "ASP.Net Web Service" in Visual Studio 2015, which I have tested to work. Leaves the question, of whether this is the best way to go for what I need.
I think that you would have better luck using web api. Calling a REST based api is a lighter load on the network and is generally easier to set up. It is also easier to call from non-Microsoft based clients and usually requires less coding to get started.
Here is a good tutorial on creating a RESTful web api using .Net Core. If you have a PluralSight subscription, they have a number of tutorials on Web Api. If you don't have a subscription, it is well worth the money.
Web Api and WCF are two completely different frameworks. WCF uses SOAP, which is XML based, meaning that the number of bytes needed to send information is much larger than a RESTful service in Web Api. It is much easier to write and deploy a Web Api application and client than it is to write the equivalent in WCF.
Does anyone have experience using ASP.NET MVC project as a Web Service?
i.e. using ASP.NET MVC without Views, so other applications can use the URL to GET or POST to the actions in the Controller.
Has anyone used it? If so, are there any drawbacks for not using Web Service project instead?
Thank you all in advance!
It really depends on the kind of application you're writing. I would actually argue the inverse of LukLed's position - SOAP-based services are better suited for internal clients when you want to support things like Windows Authentication, or different protocols like TCP or MSMQ.
Using a more web-style of GETs and POSTs around specific "resources" starts to get you into the REST architectural style. This technique has a few distinct advantages to me:
The response is usually smaller, particularly when using lightweight formats like JSON
Because of the simplicity of the requests and responses, this makes it much easier to use in mobile / native applications (see Twitter's API, for example)
The service you create can be self-describing and discoverable, because you can link to other parts of your API just like normal web pages.
One article that particularly helped me understand the tradeoffs here is Martin Fowler's "Steps Toward the Glory of REST." That being said, it may or may not be the right fit for your application.
If you do choose to build a more REST-based service, definitely consider using the ASP.NET Web API built into MVC4 as others have mentioned. It's currently in beta, but Microsoft felt good enough about it to give it a go-live license.
UPDATE:
Since ASP.NET core, ASP.NET web API has been integrated into MVC 6 project.
https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
If you want to use simple GET and POST calls, MVC will be good choice. ASP.NET MVC 4 will have support for creating HTTP based APIs. You can read about it here: http://www.asp.net/web-api
Web Service created in Web Service project can be easier to consume, because it can generate WSDL file, that can be easily read and used in many different languages (by using SOAP protocol). On the other side, WS can create huge XML responses, that could be many times smaller, if you used your own format.
If you want to spread your web service around the world, allowing SOAP will make life easier for many developers. SOAP can be used by people, who almost have no idea about programming. If you'll use it internally, prefer speed and simple requests and responses, you can use MVC.
New ASP.NET MVC includes Web Api Kit, which can do exactly what you want. With current version you can still use it. There are no real drawbacks to it
I'm developing an ASP.NET web site with a n-tier backend utilising nHibernate - all good. As part of the development a large portion of the Interface will be written in Flash or more specifically Flex 4.5. In previous projects I would've created a webservice to broker data and actions between the Flash Interface and the business logic, however I'm looking for a more flexible solution that would allow data / objects to be easily passed to and from the service endpoint without too much redevelopment and with the onus of easy consumptionby Flex and others.
Enter WCF that seems to provide a robust server-side solution where we can use the existing POCOs in the business layer that can be easily serialised across the wire, amongst other things. Unfortunately I'm unsure (and inexperienced in this field) at the best direction to enable the communication from my C# WCF webservice to my Flex application, there certainly seems a few directions but without a clear and concuse path to take.
I would also like the service to be able to communicate to other non-Flash clients so locking myself into one particular route is something I would like to avoid. After some research I believe the best approach is for the WCF service to output lightweight data (i.e. JSON) or POX that should be easily consumed by Flex and other clients. Unfortunately my prototyping has been rather frustrating where the only end to end route I've got working is to Import the Webservice into the application and setting the WCF service to use basicHttpBinding, something I believe I should be avoiding as we need to implement somekind of security and the desire to keep communication as lightweight as possible. In addition, File Uploading would have to be factored in at some stage.
In short, what is the best method to have Flex communicating with WCF (and that's even if WCF is better than say ASMX) given the brief scenario above? In addition, I would really appreciate any tutorials or links that would demostrate an end-to-end system.
Thanks in advance - S
Flex has all problems and I wish flex and flash die soon if adobe is not keep up with today technology. I had a same problem to integrate ArcGIS-flex > WCF > CRM(Oracle). I found a solution with third party. This may help you if you decide to implement your solution using WebOrb
http://cookbooks.adobe.com/post_Connecting_Flex_4_with_WCF_Services-17006.html
http://www.themidnightcoders.com/products/weborb-for-net/developer-den/technical-articles/flex-net-integration.html#c1057
I would like to write a C# app to handle my HTTP (including AJAX requests) rather than go the PHP, PERL or ASP route as I just need to return some standard HTML, albeit obviously, as I want CGI, dynamically generated.
UPDATE: I am not proposing to write my own web server but have the exe hosted by a webserver such as IIS or Apache. Also I dont want to learn and use ASP (I know I can do it much faster, development time, myself in C#) and I just want W3C valid html sent back to the client.
Are there any good reasons for not doing this?
I realise each time a HTTP request is made the exe has to be loaded and run - but surely so does Perl, ASP and PHP? Is there a way to have an exe remain running dealing with all HTTP requests for specific page? (though it feels like I am just writing a mini HTTP server then!)
Are there any good tutorials? I have read this one, but it is bit dated (2005): http://www.codeproject.com/KB/cs/cgi_csharp.aspx
UPDATE2: I dont think speed is going to be a issue anyway (running a small exe without a GUI is almost instantaneous) but if I wanted to be really efficant I could write C# server then the non-static page requests can have a tiny exe written in C which sends the request to the C# server and returns the reply. Couldn't I? :)
There are solutions such as FastCGI, that eliminate the overhead of launching an executable every time you want to process a request. Very few people still use traditional CGI. I don't know if there is a solution compatible with .net.
There is a much better option for .NET, the System.Web.IHttpHandler class.
All you have to do is subclass IHttpHandler, and overload 1 method to process a request. In my opinion it is simpler CGI.
There is a good example on the MSDN Site.
I'd suggest leveraging the HttpListener API for this kind of thing if IIS really doesn't cut it for you.
Recently, I've been very interested in APIs, specifically in how to create them. For the purpose of this question, let's say that I have created an ASP.NET MVC site that has some data on it; I want to create an API for this site.
I have multiple questions about this:
What type of API should I create? I know that REST and oData APIs are very popular. What are the pros and cons of each, and how do I implement them? From what I understand so far, REST APIs with ASP.NET MVC would just be actions that return JSON instead of Views, and oData APIs are documented here.
How do I handle writing? Reading from both API types is quite simple. However, writing is more complex. With the REST approach, I understand that I can use HTTP POST, but how do I implement authentication? Also, with oData, how does writing work in the first place?
How do I implement basic rate-limiting and caching? From my past experience with APIs, these are very important things, so that the API server isn't overloaded. What's the best way to set these two things up?
Can I get some sample code? Any code that relates to C# and ASP.NET MVC would be appreciated.
Thanks in advance!
While this is a broad question, I think it's not too broad... :)
There are some similar questions to this one that are about APIs, but I haven't found any that directly address the questions I outlined here.
A REST service can return any media-type. It could be a standardized one listed at IANA, or it could be a custom one created by you.
OData is a protocol built on to of AtomPub. AtomPub itself is RESTful, however, OData currently breaks a few of the REST constraints.
Authentication of a RESTful service is best done using the HTTP Authorization header.
You write to an OData service the same way you do with an AtomPub service. Read the spec.
Personally, I would worry about writing a valuable service that delivers content efficiently before worrying about rate limiting. You can be happy when you finally run into that problem.
For more information on caching, read this.