Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Apigee Products Best Practices

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 Solved
0 2 367
1 ACCEPTED 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 

  • you might want to enable a "read only" experience in an App, and therefore you'd want to expose only a subset of those verbs (just GET, for example) in an API Product.
  • you might ALSO want to enable a fuller read/write experience, in which case you'd need a different API Product that exposes all of the verbs.
  • You might imagine a SEPARATE experience that would rely on these verb + path combinations from one API proxy, with another set of verb + path combinations available in another API proxy.  So that's a third API Product, and that one wraps 2 API proxies.

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.

View solution in original post

2 REPLIES 2


@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 

  • you might want to enable a "read only" experience in an App, and therefore you'd want to expose only a subset of those verbs (just GET, for example) in an API Product.
  • you might ALSO want to enable a fuller read/write experience, in which case you'd need a different API Product that exposes all of the verbs.
  • You might imagine a SEPARATE experience that would rely on these verb + path combinations from one API proxy, with another set of verb + path combinations available in another API proxy.  So that's a third API Product, and that one wraps 2 API proxies.

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.