I have an azure function app (v1, with no possibility for upgrading, unfortunately) with an endpoint receiving JSON via POST requests, doing some computation and returning JSON in the response. This endpoint needs to be made SOAP-compatible, meaning that it should receive SOAP requests and return SOAP responses and also be able to provide a WSDL file.
Using the SOAP mapper in API Management is not an option, due to its limitations.
The methods I have tried are:
Create a WCF service and try to delegate the HTTP request to it from the Azure function endpoint. This didn't seem to work because the corresponding handler in WCF can only receive a request via its own HTTP endpoint (which does not seem to be exposable via the azure function endpoint), but cannot be called from within the code.
Use an ASP.net web application with SoapCore as a starting point and try to migrate it to an azure function. This doesn't seem possible because of a completely different structure. SoapCore is attached to the ASP.net app instance as a middleware, whereas azure function does not provide the means to use middleware.
Parse the SOAP request manually, convert it to JSON, do the computation, convert the result back to a SOAP message and return it. The seems very hacky and also the WSDL must be created and served manually. Despite these drawbacks, I'm leaning towards this solution because of the unfeasibility of the first two.
Is there any other possible solution that I have might missed?
If you are using Azure API Management , then below option works;
You can write transformation policies at the service or endpoint level - JSON to SOAP refer: https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies#convert-json-to-soap-using-a-liquid-template
Also refer this link Expose REST API as SOAP via Azure API Management would help.
Related
I have a Web API deployed in Azure and expose via API management. I have another API that calls that API. The problem now is that, when we try to post a data with special character. API management is blocking the request.
I understand that there are firewall rules implemented in Azure API that causes API management to blocked the request. I also don't want to disable those rules but my API should know that those strings are valid. I am planning to encode those especial character but is there a best way to do this other than encoding special characters?
What im trying is to send simple JSON data to specific Amazon endpoint. Implementation of web service that i want to request is not available in predefined form (in SDK) like AWS.EC2, AWS.SQS or AWS.S3 are.
I could also make HTTP REST request but why bother with signing and auth if there is sdk publicly available.
So again, how do i request specific endpoint with AWS SDK for .NET?
I resolved the issue by writing REST HTTP class.
Its not what i wanted to do in the first place. AWS .Net SDK does not seem to help with making such request, nor with signing.
Has anyone ever implemented batching support on top of WCF Service(not WCF data service) using HTTP multipart requests? I was looking over internet an found a tutorial over how to do the same in WebAPI and WCF Data Service but not on how to do the same in WCF Service. Any suggestion or references.
Also, if there is no in build support to do the same then how to construct the multipart response in the azure web role and what should be the return type of the request handler function?
Take a look at the messageEncoding property in the wsHttpBinding. You will want to use MTOM as your encoder for this scenario. Here is an example from the SDK.
http://msdn.microsoft.com/en-us/library/aa395209(v=vs.110).aspx
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.
Just trying to wrap my head around SOAP vs REST. We currently have some asmx web services, mostly used between our own JavaScript and server code (not a public API). When I specify my method as a ScriptService and specify a ResponseFormat of Json, is it still considered just a SOAP service? It still doesn't feel RESTful to me, but maybe thats because of the way my "resources" are designed (not well/fully represented by rest).
EDIT: Reading more I might be confusing the format (JSON vs XML) with the fact that most descriptions of the SOAP protocol tie in XML. For example, wikipedia states:
It relies on Extensible Markup
Language (XML) for its message format
To me logically that says if I'm using JSON I must not be using SOAP.
This isn't exactly what you asked, but ASMX services are not RESTful if you're calling them from JavaScript and retrieving JSON. You must make a POST request to ASMX services to get JSON out of them, even if the request is idempotent and only retrieves data. In a RESTful API, a GET request would be used in that case, not POST.
That's not to say that the lack of RESTfulness is an actual problem for a private API. I've found ASMX services as a JSON-based service layer for AJAX callbacks works great in practice.
You define what kind of requests are made to you web service (asmx). Many protocols are allowed:
HTTP POST,
HTTP GET,
SOAP 1.1,
SOAP 1.2,
etc... OR you can block any of them.
When you call the web service with javascript you can use POST or GET. It doesn't matter. The trick is what type of content you tell the service to return in these calls. You can tell the service to send you JSON or you can tell the service to send you XML.
When you create a service client in Visual Studio to connect to a ASMX service, Visual studio will try to access the WSDL for the service and the client will be in charge of generating the SOAP envelopes to communicate with the service and in this case you will send and receive XML because thats what the client and server have agreed to use to communicate.