In the past I've used Restsharp to consume restul API. RestSharp helps us get concrete type object for given operation. The problem with RestSharp is we need to manually create the POCO classes.
Wondering if we can consume the REST API similar to WCF proxy which generates all operations with signatures and also generates necessary POCO classes.
I tried using Azure API Client and having no luck i.e. not getting strongly typed objects from operation call.
When I directly query the swagger UI I get below:
......,"definitions":{"Object":{"type":"object","properties":{}}}}
I'm quiet new to this Swagger.
Looking at JSON above, should the type and properties be of given type e.g. membership and it's properties?
Am I doing the right tool i.e. azure api client?
Thanks.
For Swagger proxy generation, I use Autorest. It's made by Microsoft and published as an OSS.
It's used internally to generate barebone SDK modules from Swagger endpoints in different languages.
Related
Morning Guys
I've been trying to manage an API created in asp.net WebApi, with the WSO2 Api Manager.
I've used the following doc with no sucess:
https://docs.wso2.com/display/AM200/Create+and+Publish+an+API.
The sample shows the use of ".asmx" endpoint, and in my case I have a simple http url (http://sample.enterprise.com/api/TestService), I want to http get a jsont result by WSO2 using an url like this.
Any clues ?
Thanks
WSO2 documentation is not great. The link you provided guides you through Designing and Publishing an API, but nowhere do I see any explanation for publishing an existing API. You essentially have two choices:
Choose Design New API and define the resources exactly as they are defined in your existing API (name, action, and required parameters much match exactly). Once you reach the Implement tab, choose Managed API and provide the production endpoint for your API. If this sounds overly complicated, you also have...
Choose I have an existing API and import your API's swagger definition from file or API endpoint. Keep in mind that importing swagger directly from your API requires connections between your Publisher node and the API endpoint if you have a distributed API Manager deployment strategy.
You can find tools to help you generate a swagger definition for your APIs here. For Web API projects like ours, you might want to consider using swashbuckle from the nuGet repository.
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.
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.
Background: I have built a tool that imports sales orders from Magento to a custom application. The function salesOrderList() worked fine on a customer's Magento Go store. Then it failed on another customer's store. The reason was the former store was version 1.6.x and the latter was 1.5.x. The function call returned two different data structures on the two versions (despite being the same API version, namely SOAP API V2), causing the problem. So I customized the tool to expect the 1.6.x data structure first and then fall back to 1.5.x if the former failed. Now, we have a new customer who seems to have Magento version 1.7. The data structure seems to have changed again in 1.7 for the same function (salesOrderList()).
Programmed Using: .NET (C#); Magento SOAP API V2
Question: Is there a function call to determine the Magento (1.5, 1.6, etc.) version of the store we are connecting to? I understand from another post that there is a MAGE::getVersion() call that they use in PHP, directly on the store (without SOAP API). Is there a .NET equivalent for this when using the SOAP API?
PS: I had posted the same question (a little less wordy though) as user1236916 because I had temporarily lost the login information for this account. My apologies for the repetition.
Thanks!
The Magento core API is known to be very limited in the calls it provides by default. There is no call that returns the Magento version out of the box.
More infomation on the Magento core API can be found on the official Magento site.
That being said the Magento API is designed to be extended and to do so is not overly difficult. You will need to create a Magento module that extends one of the core API resources (you will need to do this in PHP and have access to the Magento installation itself).
See this post for more information on how to extend the V2 Magento API.
In your extended API class simple create a function like so:
public function getVersion()
{
// static method to return the Magento version within the app
return Mage::getVersion();
}
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.