We currently have one big C# ServiceStack API project for all the services within our system. I want to split this up into smaller API's that all run separately, for ease of deployment and testing. Pretty similar to what's described here by Mike Hadlow.
However, instead of using Nginx I'd like to use ServiceStack as the reverse proxy. This "external" API would handle authentication concerns and then forward any incoming request to the relevant internal API, using an async HTTP REST call.
How would I create this service forwarder, though? Let's say I have an internal API that accepts a /hello call. If I try to create a custom ServiceRunner on the external API host I cannot just intercept ANY call. It still expects certain routes to be present, so calling /hello on the external API fails. Do I need to create dummy /hello route on the external API host in order to be able to intercept them with my own ServiceRunner? Looking at the rest of ServiceStack I'm sure there's a cleaner way.
Bonus points if it can still be combined with Swagger :)
At the time this question was originally asked, there was no simple way of creating a wildcard route off the the root of the service base url. I.e. if the service was hosted at the root, there was no simple way to create a /{*} wildcard route, same if the service was hosted at another point, say /api, there was no simple way to create a /api/{*} wildcard route.
However, support for a Fallback route has recently been added to ServiceStack (see detailed example implementation.) Using a Fallback route, you can proxy all unrecognized requests to the back-end without having to enumerate them in your ServiceStack project. Doesn't provide Swagger support, however.
You can easily convert ServiceStack into a Reverse Proxy with the new Proxy Feature added in v4.5.10.
Related
I have code that calls a web service. We'll say a "3rd party" web service. So I can get the wsdl for this service, in fact I've generated a proxy class using this wsdl.
The requirement that I'm trying to meet is this: Create a web service that LOOKS just like the above mentioned one, but does other stuff. So the web service URL will be changed in a config file/database, to allow switching between the two web services.
What I'm not sure about is how I can use that proxy class that I generated, or some other method, so that the namespacing and data contract look exactly the same. I don't know much about this and these are terms that colleagues have tossed out there. I only need to actually implement one of the web service's methods in my version.
Build site with any technology you know of and return responses that match that service.
Note that if you just need to return static enough responses for occasional testing you can use Fiddler as it allows to return arbitrary responses instead of real once.
I am implementing an enterprise web application in ASP.NET MVC 5. In many situations I am writing AJAX gets and posts and communicate with the server app. Currently I am writing controller actions to serve those requests, typically returning with JSON result. The action methods parameter binding also seems work seamlessly when I passing JSON at client side.
I do not want to go far with a not appropriate practice, so the question arises, what could be the advantage to add Web API support to my project, and refactor my current ajax - controller practice?
There are few advantages according using WebAPI over MVC + Ajax:
Internal serialization
WebAPI has an internal serialization, which makes returning specific data much more easier, without your own extension method or making your controller dependent on the serialization framework library.
Action result helpers
You can use plenty of action result helpers like Ok(), NotFound(), InternalServerError(), which all return IHttpActionResult, what makes your code easier to read and maintain and clearly state your intention.
Action result abstraction
Using IHttpActionResult you can easy abstract result, which is helpful when unit testing your controllers.
Available to self-host
Using OWIN you can easily self-host your WebAPI project, what makes your application much easier to maintain and IIS-independent.
Native attribute routing
WebAPI has implemented attribute routing which makes all routing configuration much more easier(and helps when using feature-based architecture).
DI configuration improvements
Both WebAPI and MVC have their own composition roots and different DI implementation. Microsoft has introduced some improvements in WebAPI to make it easier to use and maintain.
I'd say that using MVC + Ajax was viable only when WebAPI didn't exist because there was the only option.
If your project clients needs data in multiple formats (json,xml,csv) or have chance to change in future Wep Api needs minimal configuration comparing to mvc. Wep Api returns data to client according to content negotiation (if client needs xml returns xml,if json return json according to request header ) but in mvc you need more code to satisfy that.You have to explicitly specify data format when writing action methods.(JsonResult,ActionResult,XmlResult)
Wep Api gives you more meaningful idea about what you are doing when you look at the code later.Comparing method signatures;
public List<Student> Get() has more meaning than public JsonResult Index().
Light weight & Easy to use.
Less data transfer between client and server.
Using webapi we can develop cross domain application.
Less configuration needed as compared to WCF.
It’s simple, scalable and robust because it supports all the MVC features such as routing, controllers, model binders, IOC container, action results, filter, or dependency injection as it is built on top of Asp.Net MVC.
Empower the developers by handing over control over the way HTTP protocol messages are sent and responded to.
Unit testing is easy as it support test driven development.
It provides ample flexibility in web API creation due to content negotiation and drives support for the ASP.NET routing.
Unlike WCF REST services, there is no need to define tedious configuration settings for different devices.
The architecture of web APIs is very light, which makes them a perfect alternative for the developers when they want to build applications for devices with limited bandwidth.
Web APIs are used to create non-SOAP-based HTTP Services, so if there is a requirement for web services, but not SOAP, then ASP.Net Web API is great to look for.
Supports different message format like json, plain text and xml.
Asp.Net Web API supports convention-based CRUD Actions since it works with HTTP verbs GET, POST, PUT and DELETE.
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.
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...
Before I venture down the path of creating one, I was wondering if anyone knows of a utility program which will take the REST Help page of a WCF Rest Service and create the relevant Client for C# consumption.
Similar to what svcutil.exe does for WCF Services or what wsdl.exe did for web services but for WCF REST Services
Kind Regards,
Andrew
EDIT Some more detail:
Please see this link: http://msdn.microsoft.com/en-us/library/dd203052.aspx
In the restful service using the WCF Rest Starter Kit Preview 2, they supply types which will be serialized. But My intention is be able to create clients form the help page which describes schemas. Clients could then be created for C#, JavaScript, ActionScript etc.. shearly as a strongly typed version of the restful service, not a requirement or necessity. It is a program or uitlity I am wondering exists which does this
I think you might be looking for the WebChannelFactory. It can generate a channel class based on a WCF-attributed REST interface.
Well, there will not be any use even if you would like to abstract. ALL Rest services can use HTTP verbs like GET, POST, PUT, DELETE
So, basically what your client can have is only a static class which can accept the end point, network credentials, a name value collection which needs to be passed and the verb to use.
This would be more of a utility class rather than a client.
I don't remember seeing WSDL or some contract based on which we can write clients for the REST services.
I hope you don't spend too much time basing your code on the current help page of a pre-release piece of code. Are you even sure this help page provides all the information you would need to produce clients?
Also, have you seen Prerelease 2 of the WCF REST Starter kit yet? If no, go look. There's new client-side technology in there.
Why would you create clients for a RESTful service? You don't need one - you just need to be able to initial HTTP requests. If you would like to call the same operations via SOAP or some other method then create a new endpoint for the service and a new contract and expose mex for it so that svcutil can consume it.