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
Related
This question already has answers here:
Mixing Angular and ASP.NET MVC/Web api?
(4 answers)
Closed 5 years ago.
We are currently prototyping a new web-based product.
When we started the project we decided the technology stack would be based on Bootstrap 4, Angular 4 and ASP.Net MVC 5.
As we've progressed through the project we've found that we're not really using Bootstrap as other components (such as PrimeNG) appear to be easier to use and work better with Angular.
One big thing we've noticed - which is the point of this questions - is that we're not using ASP.Net MVC.
We have a Web API layer and all our mvc controller methods are simply calling web api methods and passing data through.
My question is this: Is there any point actually using MVC? I'm starting to think we could just have Angular talk direct to the web api layer as MVC is doing nothing for us in the middle.
Does anybody have any advice as to why I shouldn't do this?
No you don't need MVC at all. You can use any server language you like - either in the form of an API (probably easier) or another GUI framework like MVC.
As you've realised, Angular is just a client-side tool and doesn't care what the back-end is - it just makes HTTP requests and receives the responses, completely agnostic of the code which was used to generate those responses.
In fact, that's one of the beauties of the web - communication between browser and server is entirely done using agreed common standards (principally the HTTP protocol, supported by things like JSON), allowing an almost limitless combination of server- and client-side frameworks to work happily together so long as they both adhere to those standards.
You would use MVC in the case that you want the angular application to be server rendered and then served to the client. Other use case where you can force this is when you want the base code to be together and deployable from one project and not two, in the case that you have one project for webapi and another for the angular application.
In this last case, deploying two different projects will have the advantage that your angular app will be completely agnostic of you backend, this means that you just need to change the endpoints of your services and bam! Running app, no? Well not really, the contra is that you will need to configurate all the CORS related crap to it so that you client can communicate with your backend.
HTML helpers is the answer to your question(it really helps). Another advantage is that it provides better coupling with model and validation.
To clearly answer this one would need to understand how back-end works. You would need to understand how html-helpers connect with the backend and help bring in clarity in development. Also for testing purpose ASP.net MVC + Angular is a better option.
So this decision(to use MVC.Net) is unlikely to come from a UI developer but from an architect who has various challenges to answer.
1) conformity with front and backend(better communication/ isolated development)
2) improve code reuse
3) validation when and where (boundaries)
4) type safety
5) easiness in bringing in new developers
6) testability
(First i just want to say i'm sorry if its not worded the best but i have been researching for hours and i thought maybe someone on here could clear this up for me)
Im new to creating web apis and i have been googling just doing some research and i have built a few MVC applications just to get exposed but i never really thought of making an API for it until today. One of the reasons its listed to be useful is it allows your application to be used across tablets and smart phones etc. What im not understanding is how you would do this as in would you just add something to the API so it makes it compatible for all browsers or if i need to re build it using Web API instead of MVC.
Thanks,
I think your looking at a Web API from the wrong perspective. It's not really about compatibility necessarily, but rather about the ability to reuse the code/back-end functionality.
So rather than having your dependencies all wrapped up in one MVC project, the references are external. This allows for essentially the same functionality across multiple projects as long as the request are being handled in the same manner.
I am looking to get into doing some iOS development for a nice addition to a project i am running.
The main project is currently written in C# and is mainly asp.net with a few windows services.
I would like to incorporate this to be able to develop a basic iPhone app as a proof of concept.
From what i have read and understand, its generally best practice to use JSON as a communication medium for iOS.
I am thinking about using WCF to create the API methods so the iOS app can connect to these services to get the data.
Are there any nice tutorials to do this?
Take a look at:
Developing RESTful iOS Apps with RestKit
I do this all the time. WCF Data Services (OData) are the way to go. With OData services, you can specify that you want JSON response by passing (Accept - Application/JSON) in the HTTP Header and OData will return JSON to you.
I have used several libraries for getting OData (which are REST services) from iOS. Microsoft's iOS OData implementation is pretty lame. RESTKit does a really good job for what it handles, but is really painful if you have to do something that it doesn't. I have also used ASI - it is much more flexible than RESTKit, but is not without problems. I ended up writing my own and it suits me just fine.
For a beginner, I would recommend using ASI over RESTKit. RESTKit, while doing a lot of the heavy lifting for you, takes a bit to get working right.
There are two things that are not standard when receiving JSON responses from OData.
1. All responses are captured in a JSONDictionary with the key of "D".
2. Dates are serialized to the JSON standard (number of seconds since 1970), but they are placed in a string like so: /Date(1212353), so you will have to parse out the Date() part of the string before you can use it.
RESTKit doesn't handle either one of these issues natively, so you will have to deal with them if you choose that route. Personally, I would go the ASI route until you learn enough to write your own.
I am considering open sourcing my solution - if I do, I will update this response with the link to it.
---UPDATE----
Just to be clear - if your server side system uses WCF Data Services, otherwise known as OData, then with minor tweaking, RESTKit plays nice with it. If your services are traditional WCF Services (i.e. SOAP Binding), then you will not be able to get JSON out of them because they are bound to the SOAP protocol (Unless you create a custom Behavior to translate it - which I wouldn't do). It all depends on what your services do in essence. If your services are typically data exposure/manipulation (i.e. addCustomer), then you should expose them as OData. If they are truly operations, then you should maybe consider exposing them as actions from a MVC site. Either of them can get you REST services using your existing infrastructure and platform.
If you're using Objective-C to develop the iPhone app, I'm not sure WCF is the best web service technology to use on the server. Check out ServiceStack to create a RESTful service.
Refer following link:
http://www.kotancode.com/2011/04/26/backing-your-ios-app-with-wcf-json-web-services/
It has included comprehensive code samples as well.
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.
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.