This section is about common antipatterns that are observed as part of the API proxies deployed on Apigee.
The good news is that each of these antipatterns can be clearly identified and rectified with appropriate good practices. Consequently, the APIs deployed on Apigee would serve their intended purpose and be more performant.
Summary of antipatterns
The following table lists the antipatterns in this section:
Download antipatterns eBook
In addition to the links above, you can also download the antipatterns in eBook format:
What is an antipattern?
Wikipedia defines a software antipattern as:
In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.
Simply put, an antipattern is something that the software allows it's "user" to do, but is something that may have adverse functional, serviceable, or performance impact.
For example, consider the omnipotent-sounding "God Class/Object".
In objected oriented parlance, a god class is a class that controls too many classes for a given application.
For example, consider an application with the following reference tree:
As the image illustrates, the god class uses and references too many classes.
The framework on which the application was developed does not prevent the creation of such a class, but it has many disadvantages, the primary ones being:
- Hard to maintain
- Single point of failure when the application runs
Consequently, creation of such a class should be avoided. It is an antipattern.
This section best serves Apigee developers as they progress through the lifecycle of designing and developing API proxies for their services. It should ideally be used as a reference guide during the API development lifecycle and during troubleshooting.