Best way to serve web services for an existing c# project - c#

What is the best way to integrate webservices to an existing C# 4 project to serve data provided by this application ?
These webservices need to be accessible by different types of client like PHP and access need to be secured.
I started investigations with WCF but it seems to be very complex for small things...
Is there any frameworks easier to implement that ?

I agree with John that WCF can be easy for small things. You may want to consider using WCF Data Services if you have an existing data context (Linq2SQL or Entity Framework) - this makes it pretty easy to serve up your data and also create custom service methods to perform specific actions.
I can provide more specific answers if you elaborate in your question what you're looking to do.
I hope this helps.

Related

WCF REST - Separate API into multiple .svc files

I am working on a Restful WCF API. I figured out it would be nice to have one service contract for API related to Users (IUserService) and then for example another one for Posts that users add to the database (IPostService). This approach makes it easier to read the code , as well as to collaborate on the code, since several people can work on separate files.
However, this way, to make a requests I would have to call <url>/UserService.svc/user/123 to get a user and <url>/PostService.svc/post/456 to get a post.
Is this a viable solution , or should I have just one service for a case like this ? If yes, is there a way how to make it easier to collaborate and read the code ? Maybe with partial classes?
I don't have much experience with theses technologies and C# in general, so I will appreciate any help :)
Thanks.
Your solution is definitely viable. And even more scalable if needed in the future than the partial classes solutions. By having the ability to split completly in multiple specialized services.

WCF to Flex : The best approach?

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

What kind of WCF services should I create for WPF application? / Domain services

I need to write server & client part. I need guidance how to start with WCF web-services.
I need to create WPF application that at the beginning will be simple UI for database tables, but later will consume data from server as WCF services.
I was looking at LightSwitch, but it seems impossible to integrated it later with server part.
In Visual Studio 2010 after I create WPFApplication1 project I have Data Sources docked window.
Then I can add new data source and select services
What kind of WCF services should I create for WPF application?
I would like something like WCF RIA Services / Domain services, but they are only for RIA.
At least no support from Microsoft. What is classic way for creating services for WPF application?
Related questions are :
Hosting WCF Rest Services in WPF Application
Architecting a WPF application with WCF Data Services
How to use WCF RIA SERVICES with WPF application?
WCF, Web services or ADO.NET data services: What shall I use?
I would suggest you to create four projects for that porpouse:
Yourapp.UI (XAML code and ViewModel)
Yourapp.Data (Data Access Layer)
Yourapp.Entities (Definition of your business objects)
Yourapp.Services (Services Layer aka WCF)
Yourapp.Data talks to database and retrieves the desired information.
Yourapp.Services maps and transforms that information into your entities (if the logic involved is too complex, perhaps and aditional business layer would be required).
From Yourapp.UI just need to add a Service Reference and consume it like a IEnumerable<> and make it reusable so VS won't create additional objects but point to your entities.
Yourapp.Entities must be referenced in projects 1,3 and 4. This will make your development easier to test and debugable. Also try to use interfases at the service level so mock testing would be easy to implement.
Hope I was clear enough, I'm kind of tired. If any question aroses, add a comment please. Cheers.
Ok, I know it was more a theory answer rather than a practical one. May I suggest you to check these tutorials? MVVM Tutorials - WCF/WPF They are excellent introduction and happens to use WPF and WCF like you require.
A couple of months ago I found them in youtube and believe me, they cleared out a lot of doubts I had at that moment. Since then it's been a lot easier to master. At the beginning WCF can seem more complicated than what it really is.
Sorry for not extending my answer but I don't have much time at this moment. Hope it make more sense now.

Expose 3rd party interface (over WCF) to Silverlight

I searched a lot, apologies if I missed something obvious. And thanks for reading the looong text below.
I have a 3rd party (read: No way to access/change the source) application here. It consists of a server (Windows service) and an API, that talks to the server via remoting.
For several reasons I'd like to expose this API over WCF (see subject: One reason is a WCF client).
The problem is, the API is
unchangeable (follows 3rd party rule)
using no WCF itself (it is serializable/MarshalByRef where necessary for Remoting)
using lots of interfaces and internal implementation classes
Following 1 I cannot use the (quite intrusive) WCF attributes myself.
Following 2 the API itself can be used "over the wire" (they support remoting via TCP and HTTP), but remoting is not good enough for me.
Following 3 I have mostly interfaces (which WCF won't handle well, cannot (de-)serialize). The implementation classes could be sent over, but - I cannot access them.
The general usage for this API is based on a single interface (and its members/properties), so the typical usage is like
var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
and so on.
What I'd really like to do is generate (with as little effort/code as possible) a proxy (not in the typical WCF sense) that I expose via WCF and that serializes this hierarchy mapping every call/property on the client to the real thing on the server.
The closest I've come so far is stumbling upon this project, but I wonder if there are more/other tools available that take a medium to large part of this work off my shoulder.
If there are any general other advices, better approaches to wrap something preexisting and unchangable into WCF, please share.
My advice is to use a facade pattern. Create a new WCF service that is specific to your usage and wrap the 3rd party service. Clients would talk to your service and you would talk to the 3rd party. But clients would not talk to the 3rd party directly.
This would work in most but not all scenarios. I'm not sure of your particular scenario so YMMV.
BTW you can look at WCF RIA Services which is good for exposing services to Silverlight where you can avoid doing a lot of the hand coding of service stuff. But again depending on your particular scenario it might not be the best way to go.
Edit:
It's now clear that the API is too big and/or the usage patterns of the clients are too varied in order to effectively use a facade. The only other thing I can suggest is to look at using a code generation tool. Use reflection (assuming it is a .NET API?) to pull apart the API and then codegen new services using the details you gathered. You could look at the T4 templates built into Visual Studio or you could look at a more "robust" tool such as CodeSmith. But I'm guessing this would be some painful code to write. I'm not aware of an automated solution for this.
Is the API well documented? If so, is the documentation in a parseable format such as XML or well-structured HTML? In that case you might be able to codegen from the documentation as opposed to reflecting through the code. This might be quicker depending on the particulars.
Okay, hair brained scheme #1 on my side:
Use Visual Studio Refactor menu to "extract interface" on 'ApiClientEntryPoint'.
Create a new WCF service which implements the above Interface and get VS to generate the method stubs for you.
'For PropertyExposingAnInterface.SomeOtherMethodCall' You will have to flatten the interfaces as there is no concept of a "nested" service operation.
Your only other option will be to use T4 code gen ,which will probably take longer than the above idea.

Creating an API for an ASP.NET MVC site with rate-limiting and caching

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.

Categories

Resources