This lesson covers what an API is and why you might want to build one. Joe also explains the basic concepts behind any API and provides real world examples of existing APIs that you're probably familiar with as well as use cases for when and why you might want to build your own.
In this lesson Joe shows you where to locate the services module and it's documentation. Then walks through installing the services module and confirming that it's working. Followed by a quick overview of the module's codebase and a general overview of what the services module provides.
Additional resources
The API that we're going to be building through this series is a REST based API so we need to understand the basic tenants of RESTful web services. In this lesson Joe gives a short presentation explaining the basic terminology, workflow, and tennants of REST based web services.
Additional resources
This lesson walks through defining the URL that will serve as the endpoint for your API as well as all the basic configuration for your new services endpoint with the exception of resource configuration which is covered in the following lesson.
Additional resources
The services module exposes most of Drupal core's data as resources and provides CRUD operations and additional actions for each. In this lesson Joe will look at the available resources, talk about the various CRUD operations and actions and then enable the node resource and demonstrate retrieving node data as JSON from the services endpoint.
Additional resources
JSON Formatter - Chrome plugin to display results of a JSON request in a nicer way.
While cURL may not be the simplest way to interact with a REST API it is the most ubiquitous and the one that is most often referenced in documentation through the web. So to ensure that students have at least a baseline of understanding, and will know how to read the documentation in the future, in this lesson Joe takes a quick look at how to test our API with cURL by retrieving, and creating data.
Example Commands:
`curl http://localhost/demos/services-7x/docroot/api/v1/node/1`
`curl --data '{"title":"hello world!","type":"page"}' --header "Content-Type:application/json" http://localhost/demos/services-7x/docroot/api/v1/node`
Additional resources
Instead of using the CLI to test our API we can use the powerful Chrome REST Console plugin instead. This provides a nice GUI and makes it a little easier to both test and understand what is going on. In this lesson Joe looks at installing the plugin and making basic requests to our API using the REST Console interface.
Additional resources
The Chrome plugin demonstrated in this video is no longer available but there are many alternatives available. Use Postman or search for "REST client" to find tooling options.
In this lesson Joe will demontrate using additional parameters and arguments to refine the returned data when making requests from our API. As well as walking through the code that shows where the various parameters are defined and how you can find what options are available. Finally, we install the services tools module which provides some additional documentation.
Additional resources
Services implements resources for all of core's basic data types but sometimes the information returned in the response is either to much or to little and we want to make changes to the response data. In this lesson Joe will look at how we can write a simple custom module that implments basic hooks provided by the services module to allow us to alter the response returned by a request to the node resource.
Most of the actions we want to perform and data we want to retrieve from an API is likely restricted to authenticated users. This lesson will outline the process of making an authenticated request and walk the user through the configuration that is required for our services endpoint in order to start allowing session based authentication.
In this lesson Joe walks through making authenticated requests to our API with cURL. Although cURL can be a bit verbose when making authenticated requests it serves as a good way to talk about all the headers that are a required and a lowest common denominator for how you could accomplish authentication in just about any language or application.
Example commands
curl http://services-demo.lan/api/v1/user/login -d '{"name":"admin","pass":"admin"}' -H "Content-type: application/json" -H "Accept: application/json"
curl http://services-demo.lan/api/v1/system/connect -X POST
curl http://services-demo.lan/api/v1/system/connect -H "Cookie: SESS60f8c5b86739b7e326223b4ef35867b2=A86XHGJWlnDcMOGcArbOT-qHrsIi5P2NrcoNTXwWluw" -H "X-CSRF-Token: T77haXwD7JKOJsBlKP3p3kLbjQO96bQWvGJAE1_PUZM" -X POST
curl http://services-demo.lan/api/v1/user/login -X POST -H "Content-type: application/json" -H "Accept: application/json"
In this lesson Joe walks through making authenticated requests using the Chrome REST Console Plugin
Additional resources
The Chrome plugin demonstrated in this video is no longer available but there are many alternatives available. Use Postman or search for "REST client" to find tooling options.
All the power of views made available to your API. Really, what else is there to say? In this lesson Joe walks through installation and basic configuration of the services views module which provides the ability to expose views as resources via the services module.
Additional resources
In addition to using views to expose lists of things via our API we can also take advantage of views exposed filters to allow API consumers more control over the data they are receiving in a request. In this lesson Joe looks at accessing views exposed filters via REST requests by adding an exposed filter to both of the perviously created views and then walking through how the configuration of the view changes the behavior of the filter when used via the services API.
In addition to the built in support for core's data and actions the services module also provides a robust framework for exposing the data and actions of our custom modules as an API. In this lesson Joe writes a basic module which creates a custom resource for saving and retrieving a "checked in" status for an authenticated user.
Example commands:
Check a user's status
curl http://localhost/demos/services-7x-test/docroot/api/v1/drupalsquare/1 -H "Accept: application/json"
Check-in a user
curl http://localhost/demos/services-7x-test/docroot/api/v1/drupalsquare/checkin -X POST -H "Content-type: application/json" -H "Accept: application/json" -d '{"uid":1}'
Additional resources
An API that exposes data and actions to a 3rd party is only as good as the documentation for that API. Without good documentation no one will be able to make use of the API you just spent so much energy creating. In this lesson Joe shows some of his favorite API documentation examples and then walks through creating some basic documentation for the resource we created in the previous lesson.
Additional resources
Example - GitHub API Documentation
Example - Recurly Documentation
http://apiary.io - tool to assit in writing good documentation
In this lesson we will convert the style guide into a series of stubs which we can view in a Web browser. The design was originally created using the templates from the 960gs. We'll use this same grid framework to ensure all of our margins are automatically adopted. Grid frameworks are excellent for rapid prototyping of designs. Ultimately many front end developers choose choose to write their own for the final theme; however, if you're just getting started try to stick with a grid framework to reduce the number of things that you need to fight with.
The original theme that was created for this design used the NineSixty base theme. There are some nifty features in this theme which are great for more complex designs; however, it is not responsive, and does not use Sass. To bring the lessons up-to-date we'll be using the 960-Compass Plugin to generate our stub files and give us some sample Sass output to work with.
By the end of this lesson you will be able to convert a style guide to a series of stub files in Sass (or CSS) using SMACSS conventions and a grid framework.
Additional resources
SMACSS (Scalable and Modular Architecture for CSS)
In SMACSS there are both major and minor layout rules that need to be created. The major layout rules are often handled by a grid framework and are used to describe big areas on your site, such as your Drupal regions. The minor rules are used for the components (for example how a picture aligns next to a paragraph of text). In this lesson we'll start by review how Sass allows us to use semantic naming for our CSS layout classes. Then we'll adapt the sample Sass provided by the 960 Compass Plugin so that it uses the necessary structure for our design.
By the end of this lesson, you will be able to implement the layout rules from your style guide as a Sass file using the 960 Compass Plugin as a reference.
Additional resources
The final step before we step back into Drupal is to create a checklist for all the things we need to implement in Drupal. Using our style guide as a starting point, we'll ensure that every design decision which has been made can be implemented in Drupal. Your checklist might also include notes about which modules should be used to build each of the components from within Drupal. Creating a checklist might seem like a trivial task, but it's really important that you know exactly what you're about to build so that you don't get overwhelmed once you step into Drupal. By the end of this lesson you should be able to create a document with all the instructions, and notes you will need to apply your style guide to a Drupal site.
Technically a theme can be installed onto any Drupal site, but it never quite works this way in real life. In this lesson we'll create a playground so that we can try out our theme before deploying it to a live server. We'll start by installing Drupal and adding some “fake” content and menus with the devel generate module. For these tasks we'll use Drupal's default theme, Bartik. By the end of this lesson you will be able to install Drupal in an environment where a development version of the theme can be safely tested.