I am about to start a project in C#. I've never used c# and I was hoping I could get some implementation advice before I make a silly mistake and go down the wrong path.
What I am trying to achieve is basically having a C# application on a server that can be accessed via a Web API. This application will take in some string variables and then return a string. The application will be opening and running some installed programs (not c# programs).
I've read about WCF but I think at first glance this might be overkill as the API I am hoping to create will only have one or two request methods and will return a string.
What I am really looking for is advice on what I should be using, what to look into and even links to good tutorials on building web services with C# and how I can make the link between a web API to a C# app.
Thanks all for any advice.
Skip wcf and asmx. Instead just implement this stuff through generic handlers (.ashx) files.
You have complete control over what comes in and goes out without having to muck around with all the XML garbage. We did this a while back and haven't looked back.
In short, I'd use WCF if my endpoints were going to be something other than the web server. I'd use asmx if I had to deliver all of the responses back as XML AND I was assured only .net clients would be accessing it.
Generic handlers are like .aspx pages but without all of the overhead of the page lifecycle. It gives you get a context object that has access to all of the http post and query string variables and it's up to you to decide what to emit back.
They are simple to implement and have none of the "what was that config setting for again?" issues.
Here are a couple pretty good walkthroughs:
http://swindelles.com/2008/07/11/creating-rest-web-services-in-c-sharp/
http://www.codeproject.com/KB/aspnet/RestServicesInASPNET2.aspx
If you think WCF might be overkill you could implement a simple ASP.NET MVC application that returns data as JSON or XML.
http://omaralzabir.com/create_rest_api_using_asp_net_mvc_that_speaks_both_json_and_plain_xml/
update: Another excellent option is ServiceStack. I've used it and it's really nice to work with.
You could look into vanilla web services. I only briefly glanced at it, but this seems like a decent guide.
You really need to take a look to the WCF Data Services they are easy to implement
http://msdn.microsoft.com/en-us/data/bb931106
I first met them when I implemented the Dino Esposito examples in March 2010 MSDN Magazine
http://msdn.microsoft.com/en-us/magazine/ee336022.aspx
I recommend you first read the Dino Example.
For a simple Web API, WCF is overkill, clunky, operation orientated and designed for SOAP based services (it does Web HTTP, but that was an afterthought).
The new kid on the block is ASP.NET MVC Web API for lightweight web-orientated architectures. Prepare to see more and more of this young upstart.
Related
In .Net, I think about a web service as being a project type that you select from the menu, define your classes and methods then .Net does all this black magic under the hood to allow someone on the other side of the world to reference my web service and start coding using my classes and methods directly within their visual studio.
So having this preconceived notion, when looking at writing REST web services using MVC 3 (I know MVC 4 has a REST api baked in but am waiting for a full release) I'm wondering all the usual stuff like "is this a good idea", "will this stand up to heavy use" and "am I just writing toy web services that other developers will laugh at".
Now I think a lot of my anxiety is probably down to microsoft not having wrapped a big, overly complicated, bloated, shiny REST package around it yet. So I'm looking to have my anxiety relieved hopefully by people telling me yes MVC web services are perfectly good things to create.
Any help?
I've done it a few times, I am still using it in production and haven't got any complaints.
I actually think its a nice solution because it so simple to setup and maintain.
Not this incredibly xml-configuration-heavy wcf stuff..
You might want to also have a look at the WebAPI stuff that is in the process of being released (.net 4.5):
http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx
It's very much to do with exposing plain html services.
I would suggest you take a look at ServiceStack: http://www.servicestack.net/. It 's not only quite mature, but it can help you produce cleaner code.
It really does depend on what you plan on doing with your application. Yes, you could write an MVC website that doubles as a RESTful service. However, you are then tying your UI layer very closely to your logic layer, and that is what you really need to consider. I am working on an MVC site with a ServiceStack REST service (already mentioned by #Ioannis) . The reason that I did not make MVC my REST service is because I did not want any changes in my UI to potentially affect any third party application that might be using my logic service. So, as long as you carefully consider the ramifications of making your site also your RESTful service, then either decision could be ok. :)
As others have mentioned here, ServiceStack provides a solid, terse REST Web Services Framework allowing you to effortlessly develop typed, idiomatic C# API's end-to-end.
ServiceStack also includes a number of high-performance components that deeply integrates with ASP.NET MVC using the ServiceStack.Host.Mvc NuGet package.
To learn more about the benefits ServiceStack can add to your MVC project see:
http://www.servicestack.net/mvc-powerpack/
I would like to code a REST based HTTP API which is accessible from .NET and any other language like for example Python.
Should I use WCF for this? Or will that make the other languages harder to interop with my API?
I want the server to carry no state at all, and I want to be able to take advantage of HTTP persistent connections because a typical clinet will make many HTTP calls in a row. (maybe 2 hours straight of calls)
I am allowed to use .NET 4.
There is new stuff coming in WCF to support HTTP and REST. See, http://wcf.codeplex.com/
I wrote an intro blog post here http://www.bizcoder.com/index.php/2010/10/28/wcf-http/
WCF can do about anything you'll need, but it has a steep learning curve. The REST Starter Kit from Microsoft is very helpful.
Another .NET REST framework is OpenRasta - I haven't personally used it, but I've heard good things about it.
You should consider WCF, ASP.NET MVC and WCF Data Services. This article has a reasonable discussion on the pros and cons of each appproach:
http://weblogs.asp.net/cibrax/archive/2010/10/08/asp-net-mvc-wcf-rest-and-data-services-when-to-use-what-for-restful-services.aspx
See also this SO question: ASP.NET MVC and WCF
I suggest you try using WCF. Create a simple web service first (with only one call) and see if it suits your needs. Shouldn't take you long to do this. You may find this tutorial useful.
The company has a PHP app that is in horrible condition. They want to start making plans to redesign it in .NET, however they need to run with the current design because of various reasons that I won't get into here.
They want to make some enhancements to the current design but do it in such a way that those enhancements can be in-part reused by their .NET version when it comes along. One idea to do this was to make the data and business logic portion of the app reside as a .NET webservice that would be consumed by the PHP end.
My question is will this cause problems in PHP? Can PHP consume .NET web services quickly and efficiently? Or is this just a bad design decision?
My question is will this cause
problems in PHP? Can PHP consume .NET
web services quickly and efficiently?
Or is this just a bad design decision?
I have two thoughts here. First to answer your question directly. I don't believe it's a bad design and if the .NET services are written language agnostic then there should be little issue.
The second thought is a "hope". I hope the choice to go with a .NET framework was not due to poorly written PHP. Changing languages because of poor implementation in my opinion is where the design fails. There will be more effort converting to a new language than there would be if the company choose to re-write the PHP and the end result would be a single unified language base with built-in legacy support. But then I'm a PHP fan.
For PHP to consume .NET webservices quickly you'll need to use PHP5 native SOAP Client API, enabling cache to store WSDL locally. If you use PHP4 you can use Nusoap, but it isn't as fast as native classes.
The whole point of having a webservice is interoperability between various development platforms. For instance twitter is a rails-based website and its services are consumed by multitude of various desktop and web applications written in .NET, java, python, etc, through its RESTful web-api. Facebook is PHP and C++ based as far as I know and how many webapps consume it's services through api. SO I don't think it's a bad idea. The question is how you implement this webservice. Meaning, do you want to use it once and then get rid of it or sue it for a long time. If the second option is true - make sure you design your webservice api with that in mind. Also PHP can easily consume XML-RPC and SOAP. I used both ( provided by a Perl based service) without any problem or big hits on performance.
I think using .NET to migrate from PHP is not the smartest choice - but that is somewhat subjective opinion. In my experience it almost always ended being an overkill, badly designed, more expensive to maintain and more buggy - because of the nature of the beast.
P.S.:
I'm not a PHP fan, but I don't believe in converting to .NET for the sake of converting. Also .NET infrastructure is more expensive to maintain and much more labor intensive.
The primary advantage of a webservice is its interoperability, or ability to be consumed by others independent of language. PHP should have something that allows it to consume webservices so that shou;dn't be too big of a deal. The disadvantage will be that it may be a little slower, but this is something you'd have to test out to see how much of an impact that has on your overall solution. Generally most solutions aren't inherently right or wrong, you have to test their usefulness to your particular circumstance.
PHP can consume .NET web services fine, as long as you stay away from WSHTTP based web services and use BASIC HTTP. You can secure BASIC HTTP web services with SSL for security.
WHen you are in Visual Studio 2008, and you have an ASP.NET (could be MVC or not, doesn't matter) project open, right click on the project and select "Add New Item." You will see see something under Web, called Web Service. This will create a .asmx file and you can find tutorials on how to create these basic web services.
Another alternative is to use Windows Communication Foundation, which has a lot of helpful classes, but it can be more complicated. The default configuration for a WCF service is WSHTTP, but it is possible to make a BASIC HTTP web service with the WCF too.
Not really much of a problem at all, just investigate your options.
Web Services can output data in a wide variety of formats. SOAP/XML are the default but there is no reason why you can't do YML, Xml serialized objects, or my current favorite JSON (which makes calling into it from a browser really easy).
Look also into WCF services, I believe they're supposed to supplant the Web Service format.
Finally, if you're looking for best practices check out Service Oriented Architecture. Its a large and varied field and this is exactly the sort of things they talk about.
This is more of a technology stack question.
the C# logic is pre-existing / legacy and is internally a multiple-machine/distributed app.
My need is to implement an overview web interface. So I've been looking at doing a prototype in Ruby On Rails.
Now my knowledge is a day or 2 old here... so correct me if i am wrong.
there used to be something called ActionWebServices (AWS) - which is now out of the core distrib. ActiveResource has taken its place in Rails 2.0. You can still get AWS by doing a gem install... (however couldn't find an AWS tutorial)
So looking at ActiveResource (Ares): Now Ares is opinionated.. it expects the target web service to be Restful, follow a certain pattern of URLs and accept XML as input
Now my question here is what do I use to implement the wrapper web service?
If I use Rails to do the web service as well.. I think I'm going to have some Ruby-C# interop issues (is it even possible? Can I do this via the MS-impl IronRuby?)
If I do the web service using an MS specific thing e.g. ASP.Net, Ares wont talk to it. Can you satisfy the Ares constraints via ASP.Net somehow?
Pardon my general ignorance of the web world.. and thanks for reading.
Ähm... Webservice process methods with data recieved via the html-actions (put, post, get, delete).
So you shoulnt have problems with rails/c#.
And if your c# webservice doesnt provide a restful interface, you can create an xml-file manualy and post it via rubys http-class:
http://ruby-doc.org/stdlib/libdoc/net/http/rdoc/classes/Net/HTTP.html#M000683
f.e.:
postdata = "<xml version=1.0><root><data1 value=1>asdasd</data></root></xml>"
response = http.post('http://c-sharp-website.com/getdata', postdata)
If you want to create the webservice as a ruby on rails application, you have to provide further information, f.e. if you want to access c# classes from your rails application.
EDIT:
You can use c# libraries with iron ruby:
http://www.kevinblake.co.uk/using-c-net-libraries-within-ironruby/602/
Maybe not the right answer.. but I took the path of least resistance and succeeded. Yay Ruby!
First I did a dummy Asp.net Xml Web service as shown in this walkthrough. Less hassle to talk to my C# code.
Next I found this uber-blog post by Ryan Heath and it was all downhill after that.
You write a tiny wrapper Ruby class like this which gets the WSDL from the parameters you seed it with. It scans the WSDL and then you can invoke your web methods as simple instance methods. Yay Ruby!
More details in my blog post in case you're piqued
I want to make a client in C# in order to create Blog posts in Drupal, so the situation is the following. In Drupal i have Services module and soap_server both enabled and when i consume the wsdl file from http://example.com/services/soap?wsdl is recognizes it properly but i don't know what to do next... I'm stuck. The lack of documentation is a big disappointment for me. Does any one try this before? Any advise will be welcome ...
Maybe you chose this design for a specific reason that you did not illustrate in your question, but - just in case this is not the case - let me point out how you could leverage the built-in functionalities of Drupal and known API's to achieve what you want in less steps.
Use the Blog API module (shipped with Drupal Core) to expose widely known and well documented API's to the outside world, via the built-in XML-RPC interface.
Blog API exposes various blog-oriented API's, which are documented here, here and here.
Use code available online to implement the webservice consumer. I know nothing about C#, but from a quick google search, it seems such code is not difficult at all to be found. For example, here's some code from microsoft for metaweblog API's.
If for some reason you need or want to implement your own API with SOAP, then you should specify what your difficulties are. I assume you already created the SOAP services by following the documentation available online, and in particular this comment and this series of screencasts.
If this is the case, what is the difficult on the C# side? As stated before, I do not develop in C#, but - at least by googling it - it does seem like there is plenty of documentation and sample code available for this.
Eventually i will reinvent the wheel ... NuSoap library is much more simple to use. After extensive survey i have successfully accomplish to consume PHP web services based on NuSoap through C# client. I will make a custom module for drupal that will use NuSoap in order to call it from my C# client.