CODEWITHSUNDEEP
amazon-web-servicesaws-api-gateway
Dan
Dan

Reputation: 4329

AWS API Gateway: When to create another API?

This conceptual question has crept into my mind after becoming more familiar with AWS. In general, I’m curious if there is a best-practice and/or convention as to when an API provider should group endpoints into a new, separate API (vs. lumping the endpoints into an existing API).

To illustrate, let’s say a Service creates digital wallet coupons on behalf of Manufacturers, to be redeemed by Consumers at a bunch of Mom & pop stores — some of the activities the Service might engage in include:

And, oh by the way, the Service might also be required to ...

So?

With AWS, it’s easy to modularize one’s backend (e.g., have an RDS instance for the database, run a few lambda functions for microservices, etc.) and load balance it all. API Gateway adds to this in that each endpoint can point to different things (lambda functions, EC2 instances via HTTP proxy, etc.).

Consequently, one approach might be to define one API in AWS API Gateway and have all the endpoints underneath it:

API: “Master”
  /coupon
    POST = create a new one (for Manufacturers)
    PUT = update an existing one (for Manufacturers)
    GET = retrieve one (for Consumers)

  /coupon/validate
    POST = verify it’s still valid (Mom & Pop store use-case)

  /apple-wallet
     /{version}
         /passes
             ... per documentation
         /devices
             ... per documentation

But would it make more sense for the Service to shave off the /apple-wallet endpoint and create an entirely new, separate API?

Alternatively, if the Service was going to publish documentation for public developers to use, would it make sense to move the Manufacturer-relevant endpoints into a separate API altogether?

Since AWS makes the effort of splitting endpoints so simple via API Gateway, are there any standard practices for when you should (or should not)?

Thank you for any insights / opinions!

Upvotes: 2

Views: 191

Answers (1)

jaimerr
jaimerr

Reputation: 208

My two cents. Think about your end-user for your APIs. You will have different developer end-users for each API set.

Your ideal situation will have each developer end-user only seeing the APIs that are relevant to them. So you should split your APIs into different Gateways according to the end-users

In the theoretical situation you describe:

  • Create an API for Manufacturers so they can integrate with you to create coupons. If you do the integration internally it will be the corporate sales and presales people who talk to the manufacturers
  • The users for the Service and End User coupons might end up being the same app developers that create an interface for both stores and users. So create a coupon API for them

Separating both should also give you security benefits as you will protect the knowledge of your Manufacturer API from the users who might try to hack it

Upvotes: 3

Related Questions