Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We have a c#net windows application. now our company decided to develop a web application using asp.net to support some of the windows application functionality on the world wide web.
so we are going to deploy some services in our windows application an let the web application to use them.
Which one is the better choice : deploying WCF services or Web services ?
Web Services is a name for services that are reachable over the web infrastructure. Classically that has meant SOAP services, but the last years REST and REST-style (JSON over HTTP but not employing full REST semantics) have grown more popular.
So first you have to choose what kind of API you want to expose: SOAP or JSON over HTTP.
Second, you need a suitable framework for implementing such a services for SOAP services WCF is the right choice. asmx services are deprecated. For JSON over HTTP you can use WCF, but WebApi is easier to work with.
WCF are more complex and powerful than ASMX. However, that also means it takes a lot more effort to write them and a lot more knowledge to handle them. ASMX are super easy to write. Unless you specifically need features in WCF, go with ASMX. That said, there's also the option of ASP.NET Web Api which is the most recent service framework. It's similar to ASMX but much smarter and nicer to work with. I would recommend Web Api if you can use it in your situation.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When ASP.NET MVC came, Microsoft announced many times in many places that it wasn't supposed to replace ASP.NET Web Forms. In other words, it's just another technology that you might find useful, or you might use Web Forms in other scenarios.
However, as companies enter into the market, they can't have a jungle of technologies, because that's too expensive. They usually select a mature technology, stick to it, build on it and extend it and reuse elements in it to reduce costs.
Now we're trying to decide to move to Owin/Katana from Web API. We just wonder if it's OK that we move 100% to Owin?
The reason I'm asking this question is because we've created a very rich codebase for Web API, including streaming, compression, authentication, normalization of UGC, support of I18N & L10N, and more.
If we want to move to Owin, we need to re-create these facilities/utilities again for Owin, because its architecture is different from Web API.
We want to move to Owin, because it's faster, lighter, self-hosted server, and seems to be the future of service technologies from Microsoft.
Is it safe for us to move to Owin completely and imagine a future in which all of our services are delivered through Owin, and we discontinue using Web API?
OWIN is just a specification, nothing more. It describes a common interface that servers and applications can both use, so that applications don't need to be tightly coupled to servers.
Katana was the first step towards decoupling ASP.NET from IIS. Work on Katana has stopped now, according to the official roadmap. The ideas and technologies developed for Katana have made their way into the next version of ASP.NET (ASP.NET Core).
It rarely makes sense to build applications on top of OWIN itself, because you're operating at the lowest level of abstraction above HTTP (literally dealing with raw requests and responses). That's usually only necessary if you are building middleware components that need low-level access.
In other words: you shouldn't rebuild your application on OWIN, because you'd be spending a lot of time reinventing all of the stuff already in ASP.NET.
ASP.NET Core is the next evolution of ASP.NET and Web API. It has all the things you mentioned: it's fast, lightweight, and can self-host. If you need to rebuild your architecture, do it on ASP.NET Core.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am new to MVC & Web API. Could you pls clarify me the below question?
Is it possible to create Restful service using MVC controller (with out inheriting apicontroller class)?
What are ways to create the Restful service?
When & why to choose the webAPI?
I will try to answer your question in general sense (following the general question),
REST is an architectural style while MVC and Web API are architectural pattern. Architectural style is a concept while architectural pattern is set of tools which are defined primarily to support, but not limited to, certain architectural style
That being said, it is possible create Restful service using MVC controller without, though MVC controller is not primarily aimed to create Restful service. In fact, a Web API controller is an MVC controller. So, in that sense MVC controller is more general.
With the same reasoning, then you can create Restful service by a couple of tools like:
WCF: Though this is primarily designed to support SOAP messaging over web, there is WCF REST developed to support making Restful services (with some overheads)
MVC: More general, having similarities with Web API. You can look other posts to find more of this out
Web API: Here you go! This is purposely designed for REST!
Some others which I might not be familiar with
Thus, we choose Web API when we want to create REST service, because this architectural pattern is purposely designed for that. If you use VS, the template for the solution is already there for you, making you easier to start your project.
Currently MVC and Web API have been combined in ASP.NET, so you can also use both of them whenever you feel needed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am working with a ASP.NET MVC website and ASP.NET Web Api service. Current architecture looks like this
Browser => UI website => Web Api service => databases
The argument to split UI and Web Api was so that we can have several different UIs (Web, Mobile, Desktop, watches, etc) all calling intermediate service to get data. However, when I need to add a new api call i need to add quite a bit of plumbing boilerplate code (+ boilerplate tests which I dislike even more).
Browser => ajax
UI => controller and web api proxy client
Web API => controller and repository
database
I am thinking, it would have been easier to combine web api with UI, as I won't need to write additional controllers and proxy to call it, however I am not sure if this is the right way to go. We have about 20 controllers and 100 api calls written in C#. I am interested to know how other people use web api together with UI projects.
Should I merge Web Api project with UI project and what are the pros and cons of doing so?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm not found answer for my question - and opened this topic.
So I want develop project.
Database:
Or Couchbase or SQL Server (right now it is not important, but I think it will be Couchbase)
Website:
Asp .NET MVC + Angular etc. - Simple Website
Web Api:
ASP .NET WebAPI
**Mobile Application (This is hard side for me)**
I'm a good C# developer - it's a reason why I want write Application by Xamarin.
If its bad idea - tell me (and tell me WHY IS BAD IDEA)
if is good framework, I have a few question:
1) How work with API
2) Or I need write for each platform(iOS, Android, WP) - service (like WCF) = (3 services?)
3) Which way better for Authentication (I want give to user option Registration by FB, Google, What's Up, etc...)
I dont know, maybe you can give me links for good topics, or same question here (I'm not found)
Or maybe you can give me a name of good course on Lynda or plularsight?
Thank you.
With ASP.NET Web API you can make a REST web service working through HTTP protocol. Any platform which supports HTTP protocol, can consume your web service.
You need only one web service for all platforms.
In current ASP.NET Web API version, you can use ASP.NET Identity which supports local account and external account through OAuth.
For example, this post shows how to consume a ASP.NET Web API in Android. And this one is about how to use external account for authentication. There're some more posts in that blog discussing about ASP.NET Web API, just spend some minutes flying over it, you'll find some useful infos.
I have no experience with Xamarin so I can't say anything about it. I write mobile app in their native platforms (Android with Java, IOS with Objective C++).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm going to be working on a project that involves a number of elements:
ASP.NET MVC website
C# console application
iPhone App
To get all these separate applications talking to the database, my immediate thought was to use a WCF Service.
However, I now need to add an API to the site to allow third parties to select, insert and update records from their own applications.
In my mind, I would just create a separate RESTful service endpoint on my WCF Service which would be locked down using authentication and would only give access to certain methods.
However, I've been reading today about the Web API feature in MVC 4 which is meant to be the latest thing for RESTful APIs?
Should I be going along the line of using the Web API? or because my other applications need a web service, should I stick with a WCF Service?
If you intend to do RESTful development then you will definitely want to use the ASP.Net Web Api (which was originally called WCF Web Api and created with the goal of "Making REST a first class citizen in .NET".
Another thing to consider is that the WCF REST Starter kit is no longer supported.
Note that using Web Api doesn't mean you have to use ASP.Net MVC or IIS even as it can be self hosted.
For handling operations which are non-CRUD in nature I'd recommend Googling "REST non-CRUD". I found this blog post RESTful URLs for non-CRUD operations (and particularly the comments interesting). If you decide you NEED to have RPC calls then those may have to be done with WCF. That said since WCF REST is being killed off I'm not sure what the best solution is going to be. Having both is probably the best answer but at the same time it's not necessarily a good answer.
Another alternative would be a WCF OData Service but I'm not sure if that gets any support from an iPhone.
One last point to make (that can be deleted in the future as this is time sensitive)
Microsoft has provided a Go Live license with the beta which means that it is supported by Microsoft and you shouldn't have any problems upgrading to the file RTM.
Service Stack also looks like an option.
Demos, overview, examples is available here.
There's no right answer here. You can certainly do fairly well with a WCF RESTful service. Or you could use ASP.NET MVC. Both are perfectly valid, and both have strengths and weaknesses.
Ultimately, I'd suggest you go with whatever feels the most maintainable to you.
I would like to note that MVC 4 is in beta, so watch out for bugs and don't go live until it's out of beta.
Since you are going to create an ASP.NET MVC web site, it would be quite comfortable to use ASP.NET Web API also because programming model is very similar and those solutions are more or less integrated with each other.
I would be inlclined to look at what has the best support on all platforms that you are going to use, I suspect the iPhone app may end up driving your choices.
If it was pure .net I would still tend to lean toweards a SOAP service - it is not considered cool these days but it generally will do what you need on most platforms without having to roll custom solutions.
EDIT
ASP.NET Web API means that .NET now provides a great framework for developing a restful API, I revise my answer to say that I would now lean towards this - progress is great!
I have the same question.
In the MSDN site,
http://msdn.microsoft.com/en-us/library/jj823172(v=vs.110).aspx
Found a video tutorial where they said that for machine cosumption like iPhone or web app clients of JSON or xml, web API is recommended option. Its around the last part of the video.
While for more complex machine to machine communication WCF is prefereable.
http://channel9.msdn.com/Series/Building-Web-Apps-with-ASP-NET-Jump-Start/Building-Web-Apps-with-ASPNET-Jump-Start-04-Building-a-Service-Layer-with-ASPNET-Web-API
Here is a screenshot from their presentation.