I am considering building some services using the new Web API that's introduced in ASP.NET MVC 4 (currently in beta version). I am quite clear on the way these services can be invoked using REST which returns responses either in JSON or xml.
However is there a way where I can add these services reference in client application and generate stubs for response objects, similar to the way .NET response objects are created when we add a WSDL reference.
ASP.NET Web API does not have any such built in capability. Short of providing some WSDL-like metadata information that the existing VS tooling could read VS 2010 does not have a way to create a CLR object from a JSON service.
However, another approach you could consider is to create a simple class library with the DTO (data transfer objects) classes that could be used by both the server and the client.
Related
I have a requirement to consume all external services like asmx, wcf ,soap based services in .net core to make it as restful and then consume in the response in angular.
I don't see any examples to configure in middleware pipeline in .net core. else we need to use httpclient or web-client in c# classes to consume that. is it better way or .net core recommended way
share your thoughts.helpful if have any examples.
There are several ways to do this. Essentially, you are making a .Net Core wrapper for the Soap service. There are many samples on StackOverflow for this as well.
You can:
1.consume a .wsdl file
2.point to a svc or asmx
3.use Postman by pointing to the endpoint and then generate the code.
The first two approaches will automatically generate a Reference class for you.
With the 2nd approach, a SoapClientInterface and SoapClient will be generated. You can use the interface for dependency injection.
If you just want to instantiate the Soap client, you can then call methods in your Soap client. The calls will be async.
If you are using DataSets or DataTables as return from the Soap client, they will instead be returned as ArrayOfXElement.
I want to build a new mobile app backend. This backend might eventually support other types of clients such as desktop or traditional web application.
In the past for multi client applications I would use this stack of technologies. SQL Server -> Entity Framework -> TCP WCF Service Endpoint -> MVC Web Application or WPF Windows Application
I know I want my mobile client to be consuming a Restful Http Web API like the types you would host in the new Azure API product. But I'm not sure if I should still do the WCF layer or not.
Couldn't all my clients consume just the Web API now? Or would it still be wise to develop the WCF service and the layer Web API on top of that?
It just doesn't seem right to be using 2 different serialization technologies at the same time.
Yes, you could replace that with Web API and create a REST API but as Tim already mentioned on his comment, that is obviously just HTTP and not all the protocols WCF supports.
Having said that, API Apps have Swagger metadata to describe what the REST URIs (endpoints) can do (e.g. methods, content types, descriptions etc.). There are a lot of Swagger SDK generators which can read the Swagger metadata and generate the code you need to consume the REST API in your application for pretty much any language out there. For Visual Studio 2013 with the latest Azure SDK, you have this capability built in as well. This is pure code generation, no tight coupling or anything, we just generate the code you were supposed to write to consume the API.
I'm very new to Asp.Net Web Apis(which Microsoft has made a part of MVC templates though we can use Web Api template independent of MVC)....Just a little background.
Coming back to my problem when my Web Service is called by a user then along the line of what my Web Service is serving comes a point where I have to deserialize a Json file to a generic C# collection and cache it in-memory and then the code inside one of the Controller actions(which is obviously a get method) checks for the in-memory cache and if it has that deserialized C# collection it gets it from there else its calls another method inside the controller which caches this generic collection in memory.
My question is ...is this possible to cache the stuff for a Web Api like what I described above...I'm quite familiar with Asp.Net page life cycle,caching and sessions etc. But not with Web Api....And my above explanation is just an abstract idea...not sure how to execute it, will it work? If yes then what namespaces would come in handy like System.Runtime.Caching or System.Web.Caching.
Your answers will be highly appreciated....
In the .NET Framework 3.5 and earlier versions, ASP.NET provided an in-memory cache implementation in the System.Web.Caching namespace. In previous versions of the .NET Framework, caching was available only in the System.Web namespace and therefore required a dependency on ASP.NET classes. In the .NET Framework 4, the System.Runtime.Caching namespace contains APIs that are designed for both Web and non-Web applications. ASP.NET Web API doesn't have dependency in System.Web.dll so I recommend you to using System.Runtime.Caching, you can put your caching logic anywhere even in separate .dll file and use it in your ASP.NET Web API project.
I am working on an MVC4 application that uses MVC controllers and it is already in production. But a new requirement is to expose some of the functionality as a web service so it is accessible to get/post data programatically by other applications. So I am thinking of introuding WebAPI in this application and use it to provide an iterface to external world as well as use the same service by the views in my application.
My question is how can I use WebAPI in my existing controllers so that I can return Views instead of raw Json data.
Thanks
I'd like to create a document in SharePoint 2013 using a call to a WCF (or any other web service) from my console application.
I've been told that WCF access is deprecated in SP13 and will be removed in future versions. Instead, CSOM is to be used (whatever that is).
My question is about the recommended approach. Is it smart to build a solution based on WCF connection (which I know very well how to do) or should I start reading up on the other approach?
CSOM stands for Client-side Object Model. It comes in three flavors; .NET. JavaScript, and Silverlight. Using CSOM abstracts some of the plumbing that you have to do when using WCF directly but ultimately, CSOM talks to a WCF service called client.svc.
If you know WCF already, you can make RESTful calls using OData to that service from your app.
Here's more info about the different API's, http://msdn.microsoft.com/en-us/library/jj164060.aspx.
Here's more info about REST access: http://msdn.microsoft.com/en-us/library/jj164022.aspx.