I was finally catching up on a number of posts I'd saved to read later and noticed the prevalent use of "Northbound" and "Southbound". I'm now starting to question whether these terms are necessary or accurate.
Dictionary definition
Let's start with the Oxford English Dictionary definition of these terms.
northbound | ˈnɔːθbaʊnd | adjective travelling or leading towards the north: northbound traffic.
southbound | ˈsaʊθbaʊnd | adjective travelling or leading towards the south: southbound traffic | the southbound carriageway of the A1.
As our interfaces are static and can't travel one can assume the intent of these adjectives in our context is to indicate that the interfaces are leading in the specified direction.
On Directionality as a descriptor
Categorizing an API by directionality is rather perplexing IMHO.
Specify directionality without a reference point is misleading For example, OVSDB is a northbound API for Open vSwitch but southbound API for an SDN controller.
For SDN controllers, there are two types of interfaces:
User-Facing or Application-Facing (formerly Northbound)
This API is designed to expose higher-order functions in such a way that they can easily be consumed by humans and programmers.
By this logic, we can include any "
Device-Facing (formerly Southbound) This API is engineered to deal with low-level operations on a network device
On Protocols as a descriptor
Specifying an API by protocol is not as bad as directionality (again IMHO). It does however get quickly confusing as it's not readily apparent who the target audience is. For instance, an application that uses REST or JSON-RPC for both user-facing and device-facing aspects.
Conclusion
Let's quit it with all the "northbounds" and "southbounds". We should go back to not caring about directionality and describe an API by it's target audience. The protocol is just an implementation detail.
@dave_tucker