APIGEE - More than 2 WSDL to Same Proxy - apigee

We are planning to create a custom webservice solution on APIGEE.
Our requirement is create a single API PROXY which should be serve for more than 2 WSDL.
All WSDL contains different Operation and Binding.
Also data type defined in schema also entirely different.
Our main objective is no need to modify the API PROXY for any customer in the future.
Also want to utilize the OAUTH service provided by APIGEE for authetication.
Can you please tell how feasible in APIGEE?

Related

Mule 4 : When Autodiscovery automatically applies a policy for a deployed API and manages it, why to add client id enforcement in API specification?

I have a question regarding Autodiscovery, and adding code fragments of policies to an API specification.
Using Autodiscovery, we can apply policies and it will be applicable to the deployed application. For example Rate limiting policy applied through Autodiscovery will work fine to manage the access of our API.
Then what is the purpose of adding Client id enforcement or adding the code snippet of this policy to the API RAML? Does this mean that once the RAML changes are done, we again need to update out code to include this new RAMl from exchange and redeploy our application?
The purpose of the snippet is to document that client_id and client_secret have to be send as part of the HTTP request to the REST API. It will also make APIKit validate that it is receiving the expected information for the policy to work.

Mule 4 : How to implement a policy in Mule 4 app and exclude API?

Scenario: After creating and adding an API in API exchange, we can add a policy like a rate limiting to it. After the policy is created we have the API fragment that we copy and paste in our RAML API specification.
My question is can we define the policy in RAML and implement the policy logic directly in the Mule app and remove the API Proxy in between.
If yes, can someone also please share the link to examples if there are any?
Add an autodiscovery element to your application. This is the Basic Endpoint use case described at https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept#proxy-endpoint-vs-basic-endpoint and https://docs.mulesoft.com/api-manager/2.x/configure-autodiscovery-4-task (assuming you are using Mule 4).
You need to configure everything manually, instead of the proxy which is autogenerated.
You can't do this in RAML as you described in your question.
but to add any policy logic other than the policies that are available in your API Manager, you can create your own custom policy and after creating upload that in your API manager and apply them.
Thanks

How to expose the data service using wso2ei

I am new to this area, can anyone please help me on this. Below is my requirement.
I have a data source and i want to access those data through REST service, i have created a data source and its giving response when executing as CURL command. Further what i want to do is need to expose that as REST service in WSO2EI and the endpoint have to be configured/publish in wso2 API manager.
Please guide me on the flow how to achieve this, I have tried my best but i couldn't make much progress.
Thanks in advance.
You can create DSS REST services by creating ODATA service [1]. If you are using ODATA, you do not need to manually define CURD operations. DSS server will automatically map RDBMS database with CURD operations.
Otherwise you can create custom REST service with Data services as it described in here[2]. Here you can define a REST service along with the SQL query that need to execute for particular request.
I found this blog[3] that contain instruction to expose Data service with WSO2 API manager with an example. This example generate ODATA service with WSO2EI and expose as managed API with WSO2 API manager as following diagram.
https://docs.wso2.com/display/EI640/Exposing+Data+as+an+OData+Service
https://docs.wso2.com/display/EI640/Exposing+a+Datasource+as+a+Data+Service
https://medium.com/wso2-learning/how-to-expose-your-database-as-a-managed-api-with-wso2-in-10-minutes-c9ac2595738b

Extracting custom HTTP Headers to be used in a DSS service

We have a WOS2 DSS service which is used as the backend of an API created in WSO2 APIM. Since management wanted to create a custom http headers (username,passwd) which will be used to verify if the users is authorized based on a db data. How can I extract header data and pass it to the dss service as a parameter to be used in the query for authentication?
You can try custom sequence option. Define your mediation logic and store that in registry. And when publishing API use that sequence.
When defining mediation logic, extract that particular http header and make that to available in the request URL. Use, HTTP endpoints for that. Define properties in your custom sequence, which can extract values from your custom header.

Should it be a WebAPI or asmx

Should I leverage an ASMX service or the ASP.NET Web API for my two simple API's?
I want to create two simple APIs in my ASP.NET MVC project. One takes in 3 parameters (currentUserID, DataType, ActionName). It returns them and an XML string of the data they have requested. The API is consumed by client-side JavaScript code. The other API receives an XML string and uses that on the server side to perform actions on the database.
I just answered a related question:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Basically, the frameworks provided by Microsoft to develop Web Services are:
ASMX. XML Services based on SOAP.
WCF. Web services based on SOAP. These services were the evolution of the traditional ASMX services and basically they focused to separate the service itself from the transport protocol. That's why you can expose the same service using several endpoints and therefore several protocols (TCP, HTTP, Named Pipes, MSMQ, HTTPS). This flexibility came with the configuration problem. One of the main complaints in the community about the WCF is the tedious and extensive configuration
WEB API. Based on HTTP not in SOAP. This new API is a new framework to create services. The main difference with the other two predecesors, is the fact that it's based on HTTP and not on SOAP, therefore you can use several HTTP features like:
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
use of verbs to define the actions (POST, PUT, DELETE..)
it contains a body that can be used to send any kind of content
It uses URIs for identifying both information paths (resources) and actions
WEB API is focused on writing services to expose them via HTTP (only on HTTP at the moment). If you want to expose your service using another protocol, then you should consider using WCF.
WEB API is based on MVC (if you want to know the reasons why it's based on MVC, they are simple)
Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.
ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.
Take the following points into consideration to choose between WCF or WEB API
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
For a more detailed comparison:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
It seems you are really doing much with Views so I think Web API would be more concise solution at this point.
If possible, I would use an Web Api Controller in mvc4. You can return an generic ienumerable list or model and it will automatically output the data to whatever format is requested such as xml or json. Its pretty amazing.

Resources