I've setup a basic ServiceStack service that provides a centralised data hub for some complex reports.
We have a few different web apps that I want to (somehow) call on this service to get the required data and go on to display reports/graphs etc etc based on that information.
What I'm unclear on is how I actually 'get at' the ServiceStack data in C# as it is running as a completely separate website. (ie; our MVC app, which was created 2 years ago, has no link to ServiceStack at all just now).
I can see how I would be able to call via AJAX; but a requirement I have is being able to, in some instances, manipulate this data in C# directly.
Do I add a service reference like regular SOAP services? Or is there a better way to do this?
The best (and recommended) way to consume ServiceStack services from a .NET client is to use ServiceStack's .NET Service Clients.
The NuGet package that contains the Service Clients is:
Install-Package ServiceStack.Client
It's only dependencies are:
ServiceStack.Interfaces
ServiceStack.Text
For the least dependency you can consume Services with ServiceStack's Http Utils which is apart of ServiceStack.Text and has no dependencies, i.e:
Install-Package ServiceStack.Text
Also worth noting as ServiceStack just sends plain JSON/XML responses over HTTP you can use any .NET HTTP Client.
Related
I've tried, but I couldn't find any info about it.
Let's say that I have some webapis for my company that other devs (or qa) are going to use in theirs applications, and for easier use of my apis I'd like to create a library with client so that I can control how other devs are communicating with my api. So basically they can just install this package, add webapi url to configuration, inject necessary dependencies and use it. Is there any pattern, guidance etc. for creating such packages with client? I'm not talking about good practices how to create web api, rest api etc, but just this specific client package.
I've tried googling some tips or guidance about this (or maybe just generic instructions), but all I could find is how to create REST API...
You can use NSwag. With NSwag you can:
Generate Open API/Swagger specification from your Web API controllers. It is just a JSON document describing you API
Include an Html/JavaScript front end in your Web API application where users can see your API and invoke it.
Generate C# clients to invoke your web API.
Useful links:
https://github.com/RicoSuter/NSwag
https://learn.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-nswag?view=aspnetcore-7.0&tabs=visual-studio
As a quick run-through, i've got the following scenario
Website which hosts c# web api services
each webapi takes a 'request' message type and returns a 'response' message type
Also a winforms client app which has its own repository that consumes the webapi services for its own use.
Is it good practice to put the request/response messages in a shared library which will be used by both the website, and by the client app bearing in mind if i update the webapi on the website, it could get out of sync with the distributed client apps, and may break functionality for them until they upgrade to the latest version.
thanks for any suggestions.
If you cannot force your clients to update to the latest version, I would create a new endpoint with a corresponding shared library for each breaking change.
http://yourservice/api/v1/GetXY
http://yourservice/api/v2/GetXY
http://yourservice/api/v3/GetXY
....
And you could set up monitoring to see which old/obsolete endpoint is not in use anymore and turn it off if you want.
I'm looking for the difference summary between ASP.NET MVC Web API and WCF Service.
I've seen this question What is the difference between Asp.Net Web API and WCF Service?
and this question WCF vs ASP.NET Web API too, but they don't summarize what I can achieve with the one, what I cannot achieve with the other.
Both can be contacted via url, I first thought that was a difference between them.
So in short:
What can I do with WCF what I cannot do with ASP.NET Web API and visa versa?
this list is by no means exhaustive.
Things WCF does that you cannot do (with ease) using Web API.
Supports SOAP based XML format.
Supports strongly typed data contracts.
Supports a single point of metadata information exchange using WSDL etc.
Supports varied bindings like TCP, Named Pipes, MSMQ, even UDP etc.
Supports varied hosting options like console apps, WAS, IIS, Windows Services.
Supports one way messaging, duplex, message queues out of the box.
Supports multiple authentication schemes like Windows, Forms, Certificates etc.
Things Web API does that you cannot do (with ease) using WCF.
Supports the full features of HTTP. (Uri based access, Http Requests/Response, Http Caching etc.) To do this in WCF you need to additional work to configure it as REST service etc.
Is Lightweight with minimal configuration.
Supports the Routing, Controller/Action MVC paradigm, Model Binding etc.
Basically Web API is an easy way to do RESTful services over Http without knowing much about Web services.
To do the same in WCF, you need to do additional work in terms of httpBindings, UriTemplates, Verbs etc. And that means, understanding WCF first. And then using WCF to implement a RESTFul service over http, which is what Web Api provides out of the box.
This is not a summary per se. Its a sort of practical guide I hope.
For me it ultimately boils down to how simple I want my front-end application code to look like, and also something to do with how to achieve maximum productivity.
Traditional WCF over http is SOAP based messaging protocol. You add a service reference in your project, and Visual Studio takes care of generating the proxy classes. And you work with the instance of the proxy classes. So when you are writing your front-end code, you have intellisense to help you. Don't be fooled. This is just the IDE making life simpler for you. Underneath its pretty complicated. But my productivity is boosted to a degree. I don't have to write proxy classes. Hence, this is what I'd opt for a c# based front-end.
Alternatively, if I had to deal with a Webapi endpoint, I do not have the luxury of any IDE generated proxy classes. Therefore I'd have write code for everything. Typically I use the HttpClient classes to talk to my web api end points. Hypothetically, I could write a proxy classes to talk to web api. But it isn't as simple as in your wcf case where they were auto-generated for you.
On another line or reasoning, if my front-end was JavaScript, then my only best bet is have the web service hosted over web api, rather than wcf. If I were to talk to wcf endpoints from Js, that would be a PITN.
So it ultimately rests on your product plan, design, project schedules, etc software development plan. All the best.
After searching the entire day about what I should use, I'm not sure what option would be best for my needs so I hope someone with more experience could help me out.
I have a winforms application (c#) and a ASP.NET MVC 4 web application (c#).
I wish to connect these, the goal is to send and receive data from the database which I use in the MVC 4 project, but from within the windows forms application. The data I send from the windows forms application to the database, is then used by the MVC 4 web application.
I am entirely new to web services / Web Api's so I can't really decide what option would be best. Any help would be much appreciated..
If you already created MVC4 project then you can add actions to any controller
and return JSON data like below :
public JsonResult GetCategoryList()
{
var list = //return list
return Json(list, JsonRequestBehavior.AllowGet);
}
or you can create new project of MVC4 and select WEBAPI template . It will create webapi project for you .It will create with example .so it will easy for to create webapi.In webapi it return data automatically convert to xml and json as per request
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web AP -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
Other Links
If you have an MVC 4 App already, it would be better to use Web API (RESTful service)
I assume you have some knowledge in building REST API (understanding of POST, PUT, UPDATE stuff)
It is simple in configuration and usage. All what you need actually is to create a new controller like:
class MyApiController: ApiController {
public Post(SomeClass item) {
....connect to db and do whatever you need with the data
}
}
You'll also should configure routing for Api.
And then in your winForms app you can simply use HttpClient class to perform api call.
HttpClient aClient = new HttpClient();
// Uri is where we are posting to:
Uri theUri = new Uri("https://mysite.com/api/MyApi");
// use the Http client to POST some content ( ‘theContent’ not yet defined).
aClient.PostAsync(theUri, new SomeClass());
Take a look at some implementation details right here:
Web Api Getting Started
Get started with WCF is not so easy as with Web API.
Given the tags you've used, my guess is that you're deciding between SOAP Web Services and WCF. Given these two, I say to go WCF. SOAP web services (as implemented in Visual Studio) are the older technology; still serviceable, but WCF can do everything an older SOAP service can do (including look exactly like a SOAP service) and more.
If you have a web service that connects your web server to your database server (these two things should be on different machines; your web server is exposed to the world by necessity, while your DB server should be locked down like Fort Knox), I see no reason why you shouldn't use that same service as-is for an internal WinForms application (using a LAN/VPN to access the service layer on the DB server). For a WinForms application that must access the data over the Internet, I would recommend reimplementing the service as a WCF service supporting secure encrypted data transfer. You can also set up the service endpoint to only accept HTTPS connections, and thus simply run your existing service through SSL/TLS.
What you choose will primarily depend on how much time-resources you can commit to resolving the problem; moving to HTTPS is a fast fix requiring little if any code changes, while reimplementing in WCF will take more time but will allow additional security measures beyond a simple secure tunnel.
Or something lightweight like Nancy: http://nancyfx.org/
We had some issues with MVC4 WebApi stuff and ended up using ServiceStack on the server side JavaScript/AJAX for web clients and RestSharp for thick clients.
One of our specific issues was the inability to auto generate documentation, significant performance differences, and better support for unit/integration testing.
Rather than advocate specifically WCF, I'd recommend WCF Data Services or OData, with the stipulation that you'll need to secure it. If you go for pure WCF, you'll see that you'll end up creating a lot of code to handle retrieving the info from a database, and then sending that information right back out to your clients. It doesn't sound that bad, at first, but after about 30 entities in a database, you'll quickly grow tired of a pure WCF solution.
OData is great, it uses Entity Framework, and it quickly opens data manipulation for an existing database or one you are going to make. It will save you a ton of development time, if you can make your service secure. The format of the data response is flexible. There are plenty of client libraries ported for other programming languages as well.
The steps for securing a service are pretty simple. Always deploy to https. Any login or registration methods , need to be post methods, that return a token (Encrypted value), or a unique secret that can be encrypted and sent back for any subsequent requests. It's better to use the token, and have an expiration on the token.. because otherwise both your service and your app whether mobile or desktop, need to have a shared encryption / decryption method.
Please forgive me for this basic and a little theoretical question as I dont know much about web services.
I m not refering WCF service, I am reffering simple service in .net / C#. I want to know how to know is it soap or rest service ?
How we can change this type from Soap to Rest and vice versa ?
Thanks
XML Web Services (aka classic/legacy ASMX web services) should not be used for active development. If you must, there is a nice walkthrough on MSDN for adding Web references in more recent versions of Visual Studio (> 2005).
On the other hand, if your web service is truly Restful then you won't be able to create the equivalent of a service reference to it. You'll need to either use the HttpWebRequest, WebClient, or the new HttpClient from .NET 4.5 (also available from the Rest starter kit which is depreciated as well).
As an alternative if you are looking to implement a client that is able to handle both situations, I would recommend HttpWebRequest to POST to the SOAP (non-WCF) service. The problem with this method is you'll likely have to wrap the request in the SOAP wrapper yourself. Luckily there are examples of doing so on the net that you can at least use as a starting point.
ASMX services are build upon SOAP. REST is simply a HTTP based, You can access(or call) your business resources the way you access the normal URLs.
For ex in products catalog system, by using asmx you create set of functions to add,update,delete products. like addProduct(),updateProduct, etc..
But in REST, you will be having single point of access, like http:\mysystem\prodcuts. To retrieve,add,update,delete products, you will be using respective HTTP verbs (GET,POST,PUT,DELETE) on the same URL.
so,technically it's not possible to convert asmx(SOAP) service to rest...