Apigee Antipattern

Not applicable

I have noticed an anti-pattern that I’m seeing in the market place and was wondering if anyone had any literature that speaks to it. My understanding of the platform is that it lays the foundation to fuel digital growth by allowing App Teams to create Experience APIs quickly to test without requiring a large investment. App Teams would be able to mash up existing enterprise APIs to create new ones so that they can build new experiences in a standardized, secure manner.

A side effect of this would be that these APIs could contain business logic and thus go counter Enterprise Integration Principles. The trend that I’m seeing is that Enterprise Architecture teams are disallowing such APIs from being created. Instead they want Apigee to remain pristine and contain as little business logic as possible, much like a traditional Enterprise Service Bus. Personally I don’t think this is correct. Is there any documentation/guidance that is provided on how to best use the platform to fuel digital growth?

0 1 542
1 REPLY 1

Hi @Zameer Andani,

I too think of "experience" APIs as being built using underlying "core" APIs and generally involve aggregation/orchestration to meet specific needs of the consumer which is often aligned with the type of application (e.g. mobile, web). That doesn't imply business logic, but you are right, business logic could creep in.

The problem with business logic built into the APIs is that the business rules could change and thus require a change to the APIs, not a situation you would want to be in if you want to remain agile. One approach would be to create business rules APIs that would encapsulate the rules and expose them as APIs (e.g. GET /customers/{id}/paymentterms).