Hello
Which approach is better for security, access granularity, and quota management: having multiple proxies for the same product, or a single proxy per product?
In which situations should each approach be used?
Solved! Go to Solution.
@melfeqy03 wrote:
Which approach is better for security, access granularity, and quota management: h
Those are not the criteria on which I would make that decision. Security and access granularity and quota management is going to be similar for either way.
Think of the API Product as the consumable unit. This is a thing a developer is going to use, to build an app or experience. so the API Product needs to have all of the relevant API calls to accomplish that task. Thinking "outside in" here is helpful. Ask yourself: what experiences do we think developer will build, what do users what to be able to do? And then curate your API Products with the right APIs to enable that.
A single API proxy might allow PUT POST GET DELETE, on various URL paths, but
Thinking "outside in" guides you to the API Products you need.
The API Proxy, on the other hand, is an implementation . It's not necessarily going to map 1:1 to an API product. One API proxy might wrap an API exposed by a bespoke custom service, and another API Proxy might wrap a third party SaaS product. And you could wrap those up into a single API Product facade, to enable the experience you want developers to be able to build.
Is this helpful?
Security, rate limiting, and access granularity are not deciding criteria here.
@melfeqy03 wrote:
Which approach is better for security, access granularity, and quota management: h
Those are not the criteria on which I would make that decision. Security and access granularity and quota management is going to be similar for either way.
Think of the API Product as the consumable unit. This is a thing a developer is going to use, to build an app or experience. so the API Product needs to have all of the relevant API calls to accomplish that task. Thinking "outside in" here is helpful. Ask yourself: what experiences do we think developer will build, what do users what to be able to do? And then curate your API Products with the right APIs to enable that.
A single API proxy might allow PUT POST GET DELETE, on various URL paths, but
Thinking "outside in" guides you to the API Products you need.
The API Proxy, on the other hand, is an implementation . It's not necessarily going to map 1:1 to an API product. One API proxy might wrap an API exposed by a bespoke custom service, and another API Proxy might wrap a third party SaaS product. And you could wrap those up into a single API Product facade, to enable the experience you want developers to be able to build.
Is this helpful?
Security, rate limiting, and access granularity are not deciding criteria here.
Hi @melfeqy03, ty for your question! I noticed that @dchiesa1 provided a detailed and insightful response (Thanks Dino). If you find this information helpful, please consider marking it as the accepted solution. This will assist other community members who may have similar questions in the future.
We appreciate your engagement in the community and look forward to your continued participation.