I am in the process of creating a product where users can use both a mobile app and browser. The APIs are exposed as REST calls. As of now these REST APIs will not be called by any third party.
Should I consider rate limiting API calls?
Short answer, yes. There are libraries out there for doing it. But if the question is just whether or not it should be done, then IMHO yes.
I have done this for personal projects and for previous employer, its not that hard. Just yesterday a friend told me how he inadvertently brought down a 3rd party service his employer was using. He made his company's services faster which lead to more requests to the 3rd party service and brought it down. So his web services were rate limiting the 3rd party service by being slow. If the 3rd party service had rate limiting this would have been avoided.
Rate limiting is important to protect downstream resources, like DB's. If you do not protect these resources you might run into an unrecoverable outage due to a spike in traffic.
Its important that you prioritize the development and deployment of this compared to the other things your new product will require... e.g. might not be needed for versions 0.x.
Related
Banks are now offering payments to be made via APIs and no longer needing to use their host-to-host (h2h) file transfer (connect direct or SFTP) integrations to make payments. The key benefit outlined is that it is a simpler way to integrate.
I am not familiar with host-to-host intergration effort but I wanted to understand how is this a benefit on the API method? as I understand for both the connectivity methods h2h or API there is still integration involved. Does this translate to less effort required in terms of integration with APIs and as a result less development resources required?
Host-to-Host and API method shared same principle, which is synchronize information between our ERP and Bank system. The difference is API method usually based on the call that we request to the bank in real-time (e.g. checking balance, request payment transfer, etc.).
While H2H will be based on batch of information sent between our ERP and Bank System within designated time (e.g. every 15 mins, or else). Both will have integration involved, but for API usually will have deeper integration compared to H2H in our past experience.
I have currently delivered a SPA (Vue.js) web application with a Java API backend. Everything is currently sitting in AWS, with the frontend being in CloudFront and the backend in ECS connecting to a RDS instance.
As part of the next phase of delivery, we are creating a B2B API. My question is that of architectural design and deployment strategy, is it commonplace to just extend the existing API with B2B functionality? Should I keep them both separate with an API gateway in front? We envisage that the B2B use eventually will outgrow the SPA use case so the initial deployment configuration needs to have the most flexibility to grow and expand.
Is there some sort of best practice here? I imagine that a lot of code would be similar between the two backends as well.
Thanks,
Terry
First off - Deciding on service boundaries is one of the most difficult problems in a service oriented architecture design and the answer strongly depends on your exact domain requirements.
Usually I would split service implementations by the domain/function as well as by organizational concerns (e.g. separate teams developing them) and not by their target audience. This usually avoids awkward situation where team responsibility is not clear, etc. If it will grow into a very large project there may also be a need for multiple layers of services and shared libraries - And at that point you would likely run into necessary re-factorings / restructurings.
So if there is a very large overlap in function between your b2b and the regular api you may not want to split the implementation.
However, you may also have to consider how the service access is provided and an API Gateway could help with providing different endpoints for the different audiences, different charging models, different auth options, etc. Depending on your exact requirements an API Gateway may not be enough and this may also require another thin service layer implementation that uses common domain services.
As part of our journey towards API-led Connectivity, we have to group our resources (i.e. API endpoints) into multiple Mule applications for the experience APIs.
In order to have meaningful names for the Mule applications while maintaining the maximum re-usability, rather than associating the consumer names with the application names (which makes the experience API tightly coupled with the current application landscape), we propose to have Mule application names to reflect the essence of the business.
The list of the options are as follows. Which one do you think is more ideal? What approach have you used in your organization?
based on Channel/Consumer
A dedicated experience API for a consumer such as WEB, CRM, Mobile etc.
uri examples:
www.example.com/example-**web**-application/v1/
www.example.com/example-**crm**-application/v1/
www.example.com/example-**mobile**-application/v1/
Pro's: - applying channel specific policies is easier, management becomes easier, smaller outage window
Con's: - reusability reduces and chances of duplication of objects across api's increases
based on Business Domain
Company data model is used. Eg - Customer, Product, Payment etc.
uri examples:
www.example.com/example-**customers**-application/v1/
www.example.com/example-**products**-application/v1/
www.example.com/example-**payments**-application/v1/
Pro's: - promotes reusability, channel agnostic, same api can be used across different consumers.
Con's: management might get complex, larger outage window, multiple consumers might be impacted
based on Customer Journey
This approach is tied to the customer's lifecycle with the organization. Eg - Prospective Customer --> Lead --> Engage --> Payments --> Customer Retain
uri examples:
www.example.com/example-**prospect**-application/v1/
www.example.com/example-**lead**-application/v1/
www.example.com/example-**engage**-application/v1/
Pro's: channel agnostic, same api can be used across different consumers.
Con's: can get increasingly big and further breakdown might still be required
Thanks.
As far I understand your question; you would like to know what URIs to be using for the endpoints of the experience APIs, right?
Based on a recent blog entry from mulesoft (July 12 2017).
Experience APIs are:
Experience APIs are the means by which data can be
reconfigured so that it is most easily consumed by its intended
audience, all from a common data source, rather than setting up
separate point-to-point integrations for each channel. An Experience
API is usually created with API-first design principles where the API
is designed for the specific user experience in mind.
Based on the examples from MuleSoft and my understanding, the experience APIs are created for one given "experience"; web, virtual reality, mobile, etc...
You are trying to create an API for a given special experience to make the consumption of the API easy for this specific client.
According to my understanding the main goal on this level is not the re-usability. You focus on re-usability on the System API and Process API level, but the Experience APIs are supposed to make the life of the developers of the different clients easier by providing exactly the interface and data they need so they don't have to communicate directly with the system and process APIs, but they get a tailor-made API, suiting exactly their special needs.
Since the experience API is tailor-made for the special experience / channel / client-application; I think respresenting this in the URI is a good idea.
I have been looking into various different APIs which can provide my the weather data I need in JSON format. A lot of these API's have certain limits such as: in order to get more requests per minute, you need to pay more money per month so that your app can make more API requests.
However, a lot of these API's also have free account which five you limited access to them.
So what I was thinking is, wouldn't it be possible for a developer to just make lots of different developer accounts with an API provider and then just make lots of different API keys?
That way, they wouldn't have to pay anything as they could stick with the free accounts. Whenever one of the API keys has reached the maximum daily request calls, the developer could just put a switch statement in their code which gets their software to use a different API key.
I see no reason why this wouldn't work from a technical point of view... but, is such a thing allowed?
Thanks, Dan.
This would technically be possible, and it happens.
It is also probably against the service's terms, a good reason for the service to ban all your sock puppet accounts, and perhaps even illegal.
If the service that offers the API has spent time and money implementing a per-developer limit for their API, they have almost certainly enforced that in their terms of service, and you would be wise to respect those.
(relevant xkcd)
I am trying to integrate a payment gateway to my ecommerce website. Should I expect an uptime guarantee from payment gateway? Ideally, I think they should have a monitoring system that can alert me if there are any issues with the gateway (I might integrate with two gateways and I can take one down if it has issues), or is too much to expect? What else should I expect from the payment gateways to facilitate any other issues? (the payment gateway I am talking of doesn't seem to have such enablers)
From many of the major payment gateways (Authorize.net, Beanstream, Paypal, etc.), you should expect very good uptime and a monitoring system in place to alert you of issues.
I've worked in ecommerce web development for 5 years. I recall just a couple of of times where Authorize.net went down for a little while. Clients were notified promptly and service restored quickly. When service does goes down, you can bet the big guys customer service lines go crazy (and so does Twitter).