I was thinking of using my own custom api gateway running on a separate box using nginx.
Is there any way in which the WSO2 API Manager can integrate to my api gateway?
In case there isn't, wanted to know if there's the possibility to run WSO2 API Manager without (or disabling) the API Gateway and if you could tell me which WSO2 API Manager's features would be unavailable.
Currently there's no way of replacing the gateway since we do the authentication, throttling, etc using synapse handlers. Here I am not sure about your use case of using nginx but what you can do is you can use nginx endpoint when you create the API or on the other way around you can route nginx traffic to API Gateway (you need to fix the API endpoints appearing in the API manager store view to point to nginx). Basically API layer need to be on top of service layer.
I 'm looking for a tool to host and publish APIs documentation so
that users of the api can browse it and test it right from the
documentation web page
If i got it correctly, you need a API store only to host your APIs.You can try enterprise store The documentation can be found here
Related
WSO2 Documentation is not clear on how does the publishing of new API works.
Is is the publisher that pushes new API to the gateways ?
or
Is is the gateways that pulls or call new API configurations from the Manager ?
or
It is done through the database ?
And which protocol and ports does is uses ? An API Call, thrift, binairy ?
Thanks
There are 2 things happening when you publish an API.
1) Persist API metadata in the database. Both the API Publisher and the API store pull these data from the database to display APIs.
2) Runtime artifact (i.e. Synapse file) is deployed in the gateway. This is done via a SOAP web service call. The API Publisher calls a SOAP web service exposed in the gateway for this.
Hope I answered your question.
In our previous regular instance-based backends, for a pretty good portion of the development process of the API, we were protecting the dev version of the endpoints with basic auth.
Is there a pattern of how to efficiently hide our serverless endpoints (API Gateway) from public, but still available for the frontend team to develop on?
Create an API key for your non-production API Gateway. A different key from any that you use in production. Give that key to your dev team, then they will be able to call your non-production API Gateway endpoints, while the API will be inaccessible to anyone without the key.
As my project is going to be deployed on AWS, we started thinking about AWS API Gateway as a way to have one main entry point for all of our microservices(frankly speaking, we also would like to use by some other reasons like security). I was playing with API Gateway REST API and I had feeling that it it a bit incovinient if we have to register there every REST service we have.
I found very good option of using AWS API Gateway and lambda function as a proxy. It is described here:
https://medium.com/wolox-driving-innovation/https-medium-com-wolox-driving-innovation-building-microservices-api-aws-e9a455cc3456
https://aws.amazon.com/blogs/compute/using-api-gateway-with-vpc-endpoints-via-aws-lambda
I would like to know your opinion about this approach. May be you could also share some other approaches that can simplify API Gateway configuration for REST API?
There are few considerations when you proxy your existing services through API Gateway.
If your backend is not publicly then you need to setup a VPC and a site to site VPN connection from the VPC to your backend Network and use Lambda's to proxy your services.
If you need do any data transformations or aggregations, you need to use Lambda's(Inside VPC is optional unless VPN connection is needed).
If you have complex integrations behind the API gateway for your services, you can look into having ESB or Messaging Middleware running in your on-premise or AWS then proxy to API Gateway.
You can move data model schema validations to API Gateway.
You can move service authentication to API Gateway by writing a Custom Authorizer Lambda.
If you happen to move your User pool and identity service to AWS, you can migrate to AWS Cognito Manage Service and use AWS Cognito Authorizer in API Gateway to authenticate.
For usecases when you adopt dumb pipes (as described on martinfowler.com) AWS API Gateway is a reasonable option.
For AWS API Gateway I'd suggest to describe/design your API first with RAML or OpenAPI/Swagger and then import into AWS using AWS API Importer.
As soon as you plan to move logic in there, such as dynamic routing, detailed monitoring, alerting, etc, I'd suggest considering other approaches, such as:
Apigee
Mulesoft
WSO2
You can also host them on an EC2 within your VPC or opt-in for the hosted version. (which does have a significant pricetag in some cases)
For describing APIs you can use RAML (for Mulesoft) or OpenAPI (ex-Swagger, for Apigee and WSO2). You can also convert between them using APIMATIC which enables you to migrate your specification across various API Gateways (even AWS).
We're trying to make Salesforce send a message to one of our APIs through WSO2 API Manager 1.9.0. However, it seems that Salesforce is unable to authenticate and recommends using IP-restrictions.
So, is it possible to allow an anonymous/unauthenticated user to use an API in API Manager? IP-restriction I can take care of with firewalls, I don't have to do that in API Manager.
When you create an API, in the Manage tap, you can select No Authentication for an API resource. Then you will be able to access the API resource without access token. See my answer for the similar question.
currently we are developing a solution with some parts of wso2 middleware stack like api manager and esb.
my problem is,,
in our solution we are maintain a DMZ layer.where you guys suppose to put api manager??is it ok if we put api manager in DMZ are or outside all layers including DMZ or a put it in inner layer.????
actually this question is realated to the best-wso2-esb-solution-for-banking-application question i asked before.
Regards,
Akila
API Manager has 4 components. The API Gateway, Key Manager, API Store and Publisher. Each of these components can be deployed in any part of the network. So to answer your question we can deploy the API Gateway component of the API manager in the DMZ and rest of the components along with any other WSO2 Products in the DMZ. The below link would provide you with a better understanding on the different deployment patterns available with the WSO2 API Manager.
https://docs.wso2.com/display/CLUSTER420/API+Manager+Clustering+Deployment+Patterns