A polarizer is a filter used in optics to control beams of light by blocking some light waves while allowing others to passthrough. Polarizers are found in some sunglasses, LCDs and also photographic equipment.
When it comes to managing an API there is often the need to control what bits of an API gets exposed and what does not. However, this kind of control is generally done at a Gateway that supports API Management rather than at the back-end API which may provide many more functions that never get exposed to a consumer.
A good example, is a SOAP or REST service that is designed to support a web portal which you also want to expose as an API so that 3rd parties can build their own applications based on it. Though your API may provide many functionalities in support of your web portal, you may not want all of these functionalities available to the 3rd party application developer for one of many reasons. And, based on many cases (as in this example), you’d find that this pattern is most useful if you find that you have an existing capability that is currently being used for some purpose, which also has to be exposed for another purpose but with restricted functionality.
While The Polarizer might be treated as a special kind of an Adapter, the key for differentiating the two in terms of API Management is based on how these two patterns would be implemented. While adapter may expose a new interface to an existing implementation with new capabilities or logic combining two or more existing capabilities, a polarizer will simply restrict the number of methods exposed by an existing implementation without altering any of its functionalities. The outcome of The Polarizer may also be similar to a Remote Facade. But, unlike the remote facade, the purpose of a polarizer is not to expose a convenient and performance-oriented coarse-grained interface to a fine-grained implementation with an extensive number of methods; it is to purely to restrict the methods from being accessible in a given context.
The polarizer also fits alongside patterns such as Model-View-ViewModel (MVVM) and Model-View-Presenter (MVP). Unlike these patterns, which are designed to build integration layers to connect front-ends with back-ends, the focus of the polarizer is to control what is being exposed from a back-end without making any consideration in favour of a front-end. We however may find situations where an implementation of an MVVM or MVP pattern also performing tasks of a polarizer.
The graphic below explains how The Polarizer pattern can be implemented by a typical API Management platform. In such an implementation, the Gateway component will simply polarize all incoming requests through some sort of filter, which may or may not be based on some configurable policy.
The WSO2 API Manager provides the capability to configure what API resources are being exposed to the outside world and thereby polarize the requests to the actual implementation. Polarization may not necessarily be a one-time activity for an API. You may decide on a later date to change what methods are exposed. The WSO2 API Manager allows you to do such reconfiguration via the Publisher portal.
When it comes to managing an API there is often the need to control what bits of an API gets exposed and what does not. However, this kind of control is generally done at a Gateway that supports API Management rather than at the back-end API which may provide many more functions that never get exposed to a consumer.
A good example, is a SOAP or REST service that is designed to support a web portal which you also want to expose as an API so that 3rd parties can build their own applications based on it. Though your API may provide many functionalities in support of your web portal, you may not want all of these functionalities available to the 3rd party application developer for one of many reasons. And, based on many cases (as in this example), you’d find that this pattern is most useful if you find that you have an existing capability that is currently being used for some purpose, which also has to be exposed for another purpose but with restricted functionality.
While The Polarizer might be treated as a special kind of an Adapter, the key for differentiating the two in terms of API Management is based on how these two patterns would be implemented. While adapter may expose a new interface to an existing implementation with new capabilities or logic combining two or more existing capabilities, a polarizer will simply restrict the number of methods exposed by an existing implementation without altering any of its functionalities. The outcome of The Polarizer may also be similar to a Remote Facade. But, unlike the remote facade, the purpose of a polarizer is not to expose a convenient and performance-oriented coarse-grained interface to a fine-grained implementation with an extensive number of methods; it is to purely to restrict the methods from being accessible in a given context.
The polarizer also fits alongside patterns such as Model-View-ViewModel (MVVM) and Model-View-Presenter (MVP). Unlike these patterns, which are designed to build integration layers to connect front-ends with back-ends, the focus of the polarizer is to control what is being exposed from a back-end without making any consideration in favour of a front-end. We however may find situations where an implementation of an MVVM or MVP pattern also performing tasks of a polarizer.
The graphic below explains how The Polarizer pattern can be implemented by a typical API Management platform. In such an implementation, the Gateway component will simply polarize all incoming requests through some sort of filter, which may or may not be based on some configurable policy.
The WSO2 API Manager provides the capability to configure what API resources are being exposed to the outside world and thereby polarize the requests to the actual implementation. Polarization may not necessarily be a one-time activity for an API. You may decide on a later date to change what methods are exposed. The WSO2 API Manager allows you to do such reconfiguration via the Publisher portal.
