I heard that rest services are moved from wcf to asp.net web api frame work.
Our web application is built on vs 2010 (asp.Net 3.5) .So still i can use wcf rest services in my web application?
Please suggest some alternatives if it is not possible.
WCF can still be used to build RESTful services1, many services are already built with it and it's not going away. What you heard is that most of the new developments in terms of new functionality in the area by Microsoft will be made in the ASP.NET Web API framework, not in WCF. But as all the services out there can attest, WCF for building web services is still a valid alternative, if it does all you need.
1 The official name is actually "WCF Web HTTP Services"; REST is a well-defined set of constraints which need to be implemented, which would give the service some useful properties. There are some people who argue that people should stop using the term REST for all HTTP-based, non-SOAP services.
Related
Some time ago, about 2 years ago, I was working on web portal that was developed in .NET 2.0. and had plenty of asmx pages.
The other day, one of my coleagues that was more adept at ASP .NET said: "ASMX is old and ugly, we shoud rewrite it". So we did it, as far as I remember we moved to ashx handler.
But now, as I'm preparing to pass 70-515, I came across one some materials that still suggest to learn asmx services (with respect to AJAX). So is that approach still valid in new ASP .NET 3.5/4.0 web projects? If so, then when & where should I use it?
Or perhaps 2 years ago, I was soo ignorant, that we used some kind of old version of asmx and we moved to new asmx.
P.S. As I was entering tag "asmx" I saw a message: "asmx is obsolete" : https://stackoverflow.com/tags/asmx/info
If you can work with WCF then yes the ASMX services are obsolete because the WCF can fully replace them with more performance and flexibility (multiple binding), functionality. If you can write a WCF service then if you will be requested to create an ASMX service for some reason there will be no problem for you to do it.
And moving from ASMX to ASHX was not a smart move because they are not for replacing each other.
Oddly we moved from ASMX to WCF and then back to ASMX. WCF has quite a few downsides, most of all is cross-platform compatibility issues. If everyone consuming your service is on .NET this isn't an issue, but not all other frameworks have supported the full stack, and frequently they just can't do what WCF produces. We also found that dealing with security and testing was a pain in WCF. If your webservice is marked secure, it has to be secure in WCF, even in your testing environment, which means getting actual SSL certs for each developer. A tremendous pain to be sure.
ASMX and WCF are technologies to build web services in .NET. WCF was introduced in .NET 3.0. Its goal is to provide a standard abstraction over all communication technologies and is a recommended way of implementing web services in .NET.
What are the differences between WCF and ASMX web services?
ASHX is a way to write HTTPHandlers in .NET. For more information on what are HTTPHandler
http://forums.asp.net/t/1166701.aspx/1
ASMX services are supported in .NET. However migrating to WCF is recommended. Also, you should write all new services in WCF.
Yes, asmx is obsolute with WCF service. you can use asmx when you are working with < 4.0 aspx.
ashx will not be exact replace of asmx.
If you have coding format issue / standard / plenty of code then you can go with MVC Web API 2 (4.0 itself). but compare to WCF you must ensure what will be the recipient's response expectation
("WCF is the evolution of the web service(ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ. but Web api only for HTTP(s)").
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.
We have an ASP.Net C# application that requires some form of a web services implementation for integration with other applications. Currently we have been looking at servicestack and also using an ESB e.g. Mule.
I am trying to figure out the best way to integrate an ESB like Mule into our ASP.Net application.
Do we need to build a web service into our ASP.Net application so that an ESB can integrate with it?
If yes what would be a good approach for selecting a web service type (e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an ASP.Net application and Mule?
Do we need to build a web service into our ASP.Net application so that
an ESB can integrate with it?
Usually it's the other way around. An integration middleware, like Mule, speaks tons of protocols just for the sake of being able to connect to existing systems without changing them.
If yes what would be a good approach for selecting a web service type
(e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an
ASP.Net application and Mule?
If your application has really no pre-existing channel you could use to integrate with (not even a simple web form HTTP POST? really?) and you want to expose an API so an integration middleware can connect to it, pick the architecture/technology that maps to the API style you're creating (REST for a resource oriented API, SOAP for a RPC oriented API).
This sounds backwards. What are you required to integrate with, and what capabilities are you trying to provide?
A web service is decoupled from its implementation, you would choose to use a web service if you're trying to expose your system capabilities in an interoperable way so that it's accessible by a broad range of clients.
What you do within a web service is up to you, i.e. you could then for example connect with your ESB. Nothing is precludes you from doing that. ServiceStack also supports hosting from within an existing ASP.NET (or MVC application) see the Hello World example for different ways of configuring ServiceStack.
REST / RPC has to do with the design of your web services and ServiceStack supports both models. i.e. inherit from RestServiceBase if you want to provide different implementations when the service is invoked with different HTTP Verbs. Inherit ServiceBase if you want the same implementation to be used no matter how it was invoked. This article shows the difference between REST vs RPC/SOAP - and how you can support both in ServiceStack.
So if your exposing a single operation (or want to support SOAP) use ServiceBase, if your exposing a 'Resource' where you want to allow it to be managed using different HTTP Verbs use RestServiceBase.
I'm pretty new to Silverlight/RIA/Asp.Net thing, and I'm trying to figure if an Asp.Net website is required (for hosting the app) if I wish to use RIA services with Silverlight?
You could use a Web Application for hosing the RIA services in which is a compiled version of a Web Site. This is a distinction made by Visual Studio for different types of web projects but that might not be what you mean.
Really though RIA is just web service that takes a certain set of parameters. You technically could use PHP and generate the same content although that seems like it might be a bit of work unless there are frameworks that already do this.
Your RIA service will need to live somewhere online though. You don't need a website with web pages but you will need to run the service in a web server like IIS and that means it probably needs to live in a web site, even if the website doesn't have any web pages.
No, you can not use RIA services without an ASP.NET application. While it is true that you can create the backend data service with PHP (or a number of other web technologies), that would not be making use of RIA services.
The basic idea of RIA services is to provide a super simply means of plumbing your data classes through ASP.NET. Mostly it is used in conjunction with an ORM and additional metadata classes in your web application. You then provide a service to manipulate your data. When you compile the solution than the work you did in the web project gets pushed into your Silverlight application (through code generation).
I need to make a change to an ASP.NET web service written a couple years ago on 2.0. I call this web service from an old 1.1 web site. I need to make some changes to the web service, so am thinking, should I rewrite this into a WCF service and if so, will I still be able to use it from my 1.1 web site?
Yes this will work. Your service will need to be at least .net 3.0, but as long as you use a basicHttpBinding or wsHttpBinding, you can consume it like any other webservice.
You can make a WCF service act and behave just like a traditional 1.1 ASMX web service, but is that what you want?
I think you need to ask yourself what featires of WCF are motivating you to upgrade.
Do you want to also expose the service as a REST-ful service? Do you need to implement message level security?
If it's just to go to the latest technology for the sake of the latest technology, I'd say stick with ASMX web services if your requirements for message and protocol security aren't that high and you're working with mostly microsoft technologies.
Writing a WCF service is regrettably more difficult than a plain-old asmx web service.
yes you can... make sure to choose the correct bindings and authentication methods