I have published an API with tier availability as bronze.
When I subscribe to that API as a different user in the store, bronze will be the only available tier to subscribe.After subscription, when I try accessing the API, I am able to hit it many times in a minute without any restriction. Why does it not restrict me for 1 request per minute?
Thanks
Are you using your local install of WSO2 API Manager or API Cloud service? In API Cloud, the tiers are all presetup and work flawlessly as far as I can tell.
For your local API Manager set up the couple things I would look at are:
Check whether the APIs that you set up require authorization - if you set them up as public without authorization key requirement - then I think there is no tier enforcement either because your tier cannot be verified without authorization.
Check your ties.xml to ensure that the throttling level for the tier is properly set up: https://docs.wso2.com/display/AM170/Managing+Throttling+Tiers
Related
I’m building a service and I’m planning to charge a fixed price for each lambda call.
How to count requests per client if the lambda function being called is the same? I’m planning to pass a client id
You can use API Gateway Usage Plans for your requirement.
After you create, test, and deploy your APIs, you can use API Gateway usage plans to make them available as product offerings for your customers. You can configure usage plans and API keys to allow customers to access selected APIs at agreed-upon request rates and quotas that meet their business requirements and budget constraints. If desired, you can set default method-level throttling limits for an API or set throttling limits for individual API methods.
A usage plan specifies who can access one or more deployed API stages and methods—and also how much and how fast they can access them. The plan uses API keys to identify API clients and meters access to the associated API stages for each key. It also lets you configure throttling limits and quota limits that are enforced on individual client API keys.
Read this docs for more detail explanation.
You can use api gateway https://aws.amazon.com/api-gateway/
"Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the "front door" for applications to access data, business logic, or functionality from your backend services."
It provides you with statistics about usage as well as different options like limit numbers of requests per api_key, etc
I'm using AWS API Gateway with quota and need increase the number of requests made to api only if my backend return response with status code 200. So, responses with status different of 200 not are accounted for quota usage.
It's possible? If not, how i could make this?
Thanks
Recently i faced the same question, my solution is a little workaround.
You create two apis with aws api gateway and also two usage plans. The first api should be the api used by your customer, the second api exists only to increase the quota usage value for an API Key, so it should be a simple POST Endpoint. Now create one free usage plan (only throttling) and one usage plan with quota limitation enabled. Then connect the free plan to your api which is responsible for processing the data and connect the quota plan to the additional quota api.
Finally create an API Key for your customer, add both usage plans. Now you only need to call your quota api with the API Key provided by your customers, when their requests were successfully.
Hope this will work for you aswell.
I actually try WSO2 API Manager in our IT and I can't found how to monitor backend WS.
Is there a way to have an alert (trace/mail/...) when :
the time response of a webservice is too high?
the Webservice is unavailable (or http code isn't 200) ?
This tool seems great but I need a monitoring part...
Perhaps I simply miss it...
Any helps ?
If you already use WSO2 APIM in production how do you manage this part?
Regards,
Mike
By Using APIM and CEP integration, you can achieve this requirement. APIM can be configured to publish thrift events into CEP and then CEP can process these events to provide necessary alerts and notifications as required.
Please refer below document for APIM and CEP integration.
WSO2 API Manager has following statistics monitoring
API Subscriptions: Number of subscriptions per API (across all
versions of an API)
API Usage: Number of API calls being made per API
(across all versions of an API)
API Response Times:
API Last Access Times: The subscribers who did the last 10 API invocations and the APIs/versions they invoked
API Usage by Resource Path: Usage of an API and from which resource path (per API version)
API Usage by Destination: To see destination-based usage tracking, you must first enable it. See API Usage by Destination.
API Usage by User: Number of times a user has accessed an API
Faulty Invocations: The number of API invocations that failed to reach the endpoint per API per user In a faulty API invocation, the message is mediated though the fault sequence. By default, the API Manager considers an API invocation to be faulty when the backend service is unavailable.
For more information, please see https://docs.wso2.com/display/AM1100/Viewing+API+Statistics
For our public hosted version of API Manager - WSO2 API Cloud - we simply set up Pingdom for both the gateway and the web UIs and exposed the public dashboard at the SLA & Support page. Pingdom also has email, sms, etc. alerts when response times get over 30 seconds.
Internally we also use various server monitoring tools like icinga.
I currently hosting my website on a combination of Amazon S3 and Cloudfront. These services have a usage-based billing. When there are no users visiting my website, I am paying next to nothing.
Now I wanted to create a simple REST API where users can invite other users. I thought about using node.js or sinatra. But when I want to host that, I need to start at least one EC2 node, which roughly costs 120$ a year. I know both Heroku and AWS have free tier options, but I am explicitly looking for usage-based billing.
Is there a service that allows usage-based billing (eg. number of requests) for a custom REST API?
Well, AWS's API Gateway provides the REST API part, with billing ...
Low-Cost and Efficient
With Amazon API Gateway, you pay only for calls
made to your APIs and data transfer out. There are no minimum fees or
upfront commitments.
but you'll still have to point it at a back end service. EC2 would incur the costs you mention, but if your 'action' is simple, you may be able to use AWS Lambda. It to is priced based on number of requests and actual compute time.
I have a question on WSO2 API Manager Clustering. I have gone through the deployment documentation in detail and understand the distributed deployment concept where in one can seggregate the publisher, store, key manager and gateway. But as per my asessment, that makes the deployment architecture pretty complex to maintain. So I would like to have a simpler deployment.
What I have tested is to simply have two different instances of the WSO2 API Manager to run in two different boxes pointing to the same underlying data sources in MySQL. What I have seen is that, the API calls work perfectly and the tokens obtained from one WSO2 instance would work for API invocation on the other API Manager instance. The only issue with this model is that we need to deploy the APIs from individual publisher components for as many WSO2 API Manager instances that are running. I am fine to do that since the publishing will be done by one single small team. We will have a hardware load balancer in front having the API endpoint URLs and token endpoint URLs for both the API managers and the harware LB will do the load balancing.
So my question is - are there any problems in following this simple approach from the RUNTIME perspective? Does the clustering add any benefit from RUNTIME perspective for WSO2 API Manager?
Thank you.
Your approach has following drawbacks (there can be more which I do not know);
It is not scalable. Meaning - you can't independently scale (adding more instances of) store or publisher or gateway or key manager.
Distributed throttling won't work. It will lead to throttling inconsistencies since the throttling replication won't happen if you don't enable clustering. Lets say you define 'Gold' tier for an API. Doesn't matter how many gateway instances you are using, a user should be restricted to access no more than 20req/min to this API. This should have been implemented based on a distributed counter (not sure the exact implementation details). So if you don't enable clustering, one gateway node doesn't know the number of requests served by other gateway nodes. So each gateway node will have their own throttle counter. Meaning - a user might be able to access your API more than 20req/min. So this is one of the throttling inconsistencies. Further, lets say one gateway node is throttled out a user but the other gateway node is not. Now, if your LB routes the request to 1st gateway node, user will not be able to access the API. If your LB routes the request to 2nd gateway node, user will be able to access the API. This is another instance of throttling inconsistency. To overcome all these issues, you just need to replicate the throttling across all the gateway nodes by enabling clustering.
Distributed caching won't work. For example, API Key validation information are cached. If you revoke a token in one API Manager node, cache will be cleared in that node. So a user can't use revoked token via that API Manager node, BUT he is able to use the token via the other API Manager node until the cache is invalidated (I guess 15 min by default). This is just one instance where things can go wrong if you don't cluster your API Manager instances. To solve these issues, you just need to enable clustering, then the cache will be in sync across the cluster. Read this doc for more details on various caching available in WSO2 API Manager.
You will be having several issues if you don't have above features. WSO2 highly recommends distributed deployment in production.