Can you recommend a library/simple approach to calling REST API services from ASP.NET MVC3. In Nuget I see things like RESTSharp, Hammock, Craig's Utility Library. I am looking for a common helper that I can then plug in multiple services.
Many thanks.
Starting a new MVC4 project comes with some default Microsoft WebApi packages for publishing and communicating with REST Apis - so if you have the opportunity to do this in MVC4 I would take it.
If not, you can still bring in the necessary nuget package into an MVC3 project to consume an api.
Install-Package Microsoft.Net.Http
The you can do things in your controller/domain layer like:
var client = new HttpClient();
var uri = "http://www.myapi.com";
var content = client.GetAsync(uri).Result.Content;
Related
I have a working self-hosted OWIN based 2.2 WebApi project. I wanted to put authorization into it and share the identity service with my MVC 5 website. (There a numerous opinions on if or how easy doing so may be.) My attempt to share the authorization/authentication cookie has lead me into a hole. I discovered that the WebApi code was not seeing/processing the cookie even though it was in the request header. I then decided to try a test in which I would generate the cookie in the WebApi on one call and accept it on another. That attempt lead me to the fact that CreatePerOwinContext is not working as I thought it should.
I placed the following code in a method to generate the cookie.
var ctx = Request.GetOwinContext();
var asim = ctx.Get<ApplicationSignInManager>();
asim.SignInAsync(user, false, false);
and discovered that the Get was returning null. I then investigated the code in my startup
appBuilder.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);
I placed a breakpoint on ApplicationSigInManger.Create and never reached it. I placed a breakpoint at the same location in my MVC 5 code and did hit the breakpoint. Yes, I did verify that I am reaching and continuing past the call to CreatePerOwinContext. The lack of hitting the breakpoint has lead me to conclude that the call to CreatePerOwinContext is not working the same in WebApi as in MVC 5.
Both the MVC project and the WebApi project are using .Net 4.6 release code and the latest versions of their respective NuGet packages.
I have a tool that communicates with Gemini platform using .net API
CounterSoft.Gemini.Commons, Version 4.0.1.3038
Assembly CounterSoft.Gemini.WebServices, Version 4.0.1.3038
Now Gemini is going to be updated on the site I'm connecting with. AFAIU I have to update .net Gemini API wrappers too.
The problem is that API has been changed and it is a little bit tricky to find method in the new version.
Is there any howto guide?
I've checked http://docs.countersoft.com/rest-api/ but unable to find replacement for IssuesService.GetMyWork() method. In 4th version it return all issues that belongs to current user. I've tried to use Reflector but it fails to find something like GetMyWork method
Regards,
oleksa
We had to go through the same process and couldn't find a guide for it. However, what we did for "My Work" is use the GetFilteredItems method and passed in the resource in the filter:
IssuesFilter filter = new IssuesFilter();
filter.Resources = "1"; // Your user id
var myItems = service.ItemService.GetFilteredItems(filter);
This article suggests it was possible, or in the works, with some code that suggests it can be done, but I can't figure out what code needs to happen or the WcfTestClient's uri needs to be.
Here's the code from the article that makes me think I can do it:
// Metadata routes to support $metadata and code generation in the WCF Data Service client.
configuration.Routes.MapHttpRoute(
ODataRouteNames.Metadata,
"$metadata",
new { Controller = "ODataMetadata", Action = "GetMetadata" }
);
Is this feature implemented?
No, it does not work as you intend. WCF Test Client supports talking to SOAP-based services. OData is not supported in the current version.
Granted, as #Snixtor mentioned, you could create a SOAP service using ASP.NET Web API, including support for metadata (WSDL). But I really don't know of any good reason why anyone would want to do that.
Scenario: I'm running code on the client that connects to a server and uses a web service to retrieve data about a SharePoint list. I'm using the Visual Studio 2010 "service reference" to get a web service for my SP Site and get my data from the list. It works. Now how do I go about coding it such that when I want to move from Test to Production, my web service calls will still work? Note that the web service is a SharePoint web service, I did not write it. I am only using it. Is what I am suggesting possible? I do have the ability to ensure that the Site is the exact same (except for URLS) on both environments (e.g. backup the SP site and put it on production). Thanks for any suggestions.
Summary:
Basically I'm looking for the best way to go from test to production without re-compiling my code which consumes the SP web service. Also, as a side note, if anyone knows how similar the test/production sharepoint sites have to be, [in order for the web service to work on both without anything but the URL being changed].. that would be helpful info.
Solution
The project configuration file can be used to specify the web service location. The .svcdatamap and other files in the VS project are for design time use only, and the URL which is actually used to connect to the SharePoint web service is passed as an argument to the System.Data.Services.Client.DataServiceContext object. This is only tangentially related, but to create your own WCF web service see this link. BTW, the web service will work without recompilation anywhere the SharePoint List has the same List name and the column you're querying has the same name.
As far as I know, Visual Studio Tools for Office projects allow you to have an app.config file in your project. I'd expect that Visual Studio created the app.config file and added the necessary configuration settings related to the web service reference. In any case, you need to store the correct web service url somewhere - app.config, registry or even a database.
If you are not able to store the web service endpoint address information in the app.config file, there's a way to configure the proxy manually.
If it's a .asmx reference added as a legacy "Web Reference" in Visual Studio then all you need to do is set the Url property value of the proxy object before you call any web service methods. For example:
MyASMXWebService proxy = new MyASMXWebService();
proxy.Url = "web service url";
proxy.HelloWorld();
If it's a .svc WCF service reference then things get a bit more complicated. You'll need to create your web service endpoint programmatically. For example:
BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress endpoint = new EndpointAddress("web service url");
ChannelFactory<IMyWCFWebService> factory = new ChannelFactory<IMyWCFWebService>(binding, endpoint);
IMyWCFWebService proxy = factory.CreateChannel();
proxy.DoWork();
Since SharePoint services (SVC) do not provide a proxy, option 2 will not work. References to both locations must be included in your application and then use a parm to differentiate production from test. I believe 2013 will likely correct this bug.
You have to edit the URL in your project's web.config
Simple SharePoint example:
MyService.ListsSoapClient client = new MyService.ListsSoapClient();
client.Endpoint.Address = "site url"+"/_vti_bin/lists.asmx";
So... I have a business object/manager which is going to generate emails.
These emails will contain links to various content on the website... and therefore needs to understand about MVC routing.. or at least how to generate URLs for the website...
However my business object will not have access to a RequestContext etc and the email generation is not necessarily the result of a web request to a website (I have a dispatcher which runs on a background thread which will be generating the emails)
Any ideas how I can generate my urls without having access to a request - and therefore being unable to use URLHelper...
Thoughts?
In order to get at the UrlHelper outside of the controller, you need to feed it and the routing data the HttpContext. Here's an example:
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
HttpContextBase context = new HttpContextWrapper(HttpContext.Current);
UrlHelper helper = = new UrlHelper(new RequestContext(context, RouteTable.Routes.GetRouteData(context)));
I prefer to define schema and make both routing and business logic aware of it. Means different implementations of the same URL schema.
Some reasons why:
Your routing mechanism could change. For example in feature you can switch to url_rewrite module.
Possible issues with load-balanced installation.
You do not need even to try to use URLHelper in undocumented way.
BTW, you can replace HttpRequest from URLHelper easily. We used to use this for unit-testing. For more information just search for unit testing of the HttpContextBase or look at examples in source code of the MvcContrib. This can help to instantiate URL helper and all related stuff in non hosted environment. But I still do not think that this is a good idea.
In ASP.NET MVC5 (and possibly MVC4 - I'm not sure when it was introduced), you can do this more directly using HttpRequest.RequestContext. Eg:
var urlHelper = new UrlHelper(HttpContext.Current.Request.RequestContext);