Drupal's role-based access control is one of its strengths. Permissions and roles are well-understood, and the system is mature. But the moment you step outside the standard cookie-based session — say, into OAuth with the authorization code flow — you hit a wall that the core permission model never anticipated.

Last week, there was a trending hot take on social media: why bother with HTTP methods beyond GET and POST in your API? The argument was that URLs are cheap, so why not create more API URLs rather than using the same URL with different HTTP methods? It was a very interesting thought process around API design because it is the opposite of my thinking.

Drupal 8 ships with the RESTful Web Services module which allows you to expose various API endpoints for interacting with your Drupal site. While the community is making a push for the JSON API module, I have found the core' RESTful module to be pretty useful when I have custom endpoints or need to implement Remote Procedure Calls (RPC) endpoints. However, using the module and enabling endpoints is a bit rough. So, let's cover that! Also note, this blog covers the content from the introduction of the Web Services chapter from the Drupal 8 Development Cookbook.

A recent project of mine has been ContribKanban.com for the Drupal community. The name speaks for itself - it provides a way for contributors to work on Drupal.org project issues queues through a kanban board. This app has two purposes: visualize the Drupal.org project issue queues in a useful fashion, and provide an experiment that tries to fully utilize Drupal.org APIs.

I've been hard at work in the labs revamping the Facebook Album plugin for WordPress. Very soon you will be able to use a Facebook application to authenticate with the Facebook API.

Google+ has released a rough outline on their API for accessing data.  The Google+ API only allows for read-access to data, but this will still allow you to integrate a visitors social features around Google+.