Skip to:


NOTE: this page should be renamed to ExternalVersusInternalAPI with the corresponding name change reflected in the "Proposals and Ideas" section of NextGenApi

External Versus Internal API Considerations

When talking of an API for WordPress or BuddyPress, it makes sense to think in terms of an Internal API versus an external API. There are many services that can be exposed to plugin developers (coders) that truly amount to nothing more than providing internal access to data display and manipulation via classes, methods, and functions.

However, exposing data to the outside world, in other words for other websites and out-of-domain services to access, is an entirely different matter. This requires an external API, an API that is exclusively dedicate to providing gated access to the outside world to a site’s internal data.

A. External API Considerations

As one of the roadmap goals for BP 1.4 is integration of the Open Stack, it is imperative that sufficient forethought be given to an external API.

One aspect of the Open Stack is integrating the OAuth protocol. You can read more about OAuth, BuddyPress, and Privacy here:

One potential problem in developing an external API is that since PHP5 cannot be required at this time, there is no way to use private and protected member variables and methods. This will make coding an external API much more difficult.

This is one of the issues that is holding back the development of an external API for the BuddyPress Privacy Component. Without an external API, the Privacy Component will not be able to communicate safely with OAuth. This means that until there is a way to provide safe external data access and transfer to the outside world, integration of the Open Stack may not be desirable, maybe not even practical.

B. Internal API Thoughts

  1. The Internal API should help move BuddyPress toward more of the feel of a framework. This would offer coders and designers an easier way to create their vision of a social network, to more easily customize their BP installation. Although Site Admins can turn off various BP components, once they are turned on, the only differentiating factor between one default BP site and another is its design.

There should be options that a decent coder can use to  quickly modify their version of BP, to mold it into something other than a plain-vanilla BP install that just has a unique design. Currently, coders must write a major plugin to change the way in which BP functions out of the box.

One way to do this is to effectively decouple, as much as possible, each component from the other. In other words, make BuddyPress a module-based framework instead of a plugin suite that other plugins tie into.

Currently, a number of BP core components heavily depend upon parts of other BP core components to function. This means that there are a number of checks and balances that are hard coded to make sure that component x is enabled so that component y can do its thing. The internal API should facilitate this process in a more extendable way.

  1. As stated above, BuddyPress needs to be modular in design. See the last part of this post in this thread thread:
  1. Users are the foundation on which a BuddyPress network is built. So, having an option to disable the Xprofile component does not make sense. If the definition of BuddyPress is truly, “Social networking in a box,” as Andy states, then users and only users are the core concept. All other items are features, are components, are modules.
  1. Many of the multidimensional arrays that are strewn throughout the BP code base need an easy way to be read and utilized. As an example, each of the settings screens in the BuddyPress Privacy Component go through a series of convoluted nested loops (array traversals) simply to grab and organize the data from a given array heap.

Creating classes that would do this programatic gymnastics for developers would be extremely useful.

  1. Privacy is a key component that is sorely missing from BP’s core. The BuddyPress Privacy Component will be released soon and work with BP 1.3 and WP 3.0. It is a very robust, feature-rich component. It could be added as a core BP component without much additional work, although refactoring may be necessary if the rest of BP’s core significantly changes.

A Privacy API is already in the works. It will allow others to extend privacy to their 3rd-party plugins. But this is not an easy task since private and protected member variables and methods cannot be used. This also means that creating an external-facing API will be difficult. How will we be able to filter, in a safe and effective way, a given member’s privacy settings via an outside request from OAuth without private and protected variables and methods? That question needs to be addressed.

A little bit about ACL’s and BuddyPress.

People email me, post within the BP forums, comment on Twitter, or comment on my blog about the need for role-based ACL in BuddyPress just like all other frameworks provide. But they do not understand ACLs as they apply to BuddyPress. They fail to remember that WordPress is the foundation of BP, that roles are defined in WordPress not BP.

Typically, Access Control Lists (ACLs) and protocols focus on flexibly setting access rights to resources based on predefined roles (for example: site admin, group admin, moderator, editor, contributor, member, user). This type of access control is more often called, and more appropriately referred to as, role-based access control (RBAC).

Role-based AC is necessary when two or more people are involved in the management, oversight, and even ownership of specific subsets of data. This group of people then need to be jointly authorized to perform certain functions.

But BuddyPress is a user-centric platform where there are currently no-jointly owned or controlled subsets of data. Ignoring the overall Site Administrator, in BuddyPress, there is a one-to-one relationship between a given piece of data and a single owner of that data. Thus the BuddyPress Privacy Component is a light-weight ACL implementation. A fully-featured RBAC-based ACL is not required.

Remember, blogs are the domain of WordPress, not BuddyPress. So, whereas blogs can have multiple assigned roles, any RBAC (role-based access control) for blogs must be offered at the WordPress level and not BuddyPress.

The only possible place where RBAC makes sense in BuddyPress is at the group level where there are group users, group moderators, and group admins. However, I do not believe that the current vision of Groups in BP necessitates creating something as complex as a fully-functioning RBAC ACL implementation. It may be a nice option to have, but it does not need to be a core feature at this time. I would suggest putting that off until BP 1.5 if even then.

Last modified 10 years ago Last modified on 04/20/2010 02:54:11 PM