Drupal Web Services

Integrate social and multimedia Web services and applications with your Drupal Web site.

• Explore different Web services and how they integrate with the Drupal CMS.
• Reuse the applications without coding them again using the Web services protocols on your Drupal site.
• Configure your Drupal site to consume various web services by using contributed Drupal modules for each specific task or application.
• Drive the content from your Drupal site to Facebook, Twitter and LinkedIn using effective Drupal Web services
• An easy to follow guide that opens up a method of easily sharing data and content resources between applications and machines that are running different platforms and architecture.      

What are web services?

In order for our Drupal site to communicate and interact with other web applications, such as Flickr, Amazon, Mollom, or Twitter, we need to use standard communication protocols in the web development world called web services. Web service protocols will allow applications that reside on external websites and servers to interact and communicate with our Drupal website that is running on our own server. Web services will also allow our Drupal site to pass along content and data to external web applications existing on remote servers.

When we define web services, we need to point out that this type of communication provides for interoperability. This means that a web service communication can happen between two completely different environments but still work because we use standard protocols to make it happen.

Web services allow us to call another application on a remote server. A good analogy to this is using your cell phone to call a friend or colleague. You have one type of cell phone using one type of cell phone service. You call your colleague’s cell phone. They have another type of cell with a different service provider, but the call goes through and is successful because the two services communicate with each other using standard cell phone communication protocols.

The web service call happens through coded protocols that are translated into a language and standard protocol that both computers can understand. Generally, this is done by using the XML language to translate the programmed request into the other external applications. Web applications have a standard in which they can usually read XML files. XML is a text-based format, so nearly all computer systems and applications can work with the XML format.

The web services protocol also uses a concept called remoting or Remote Procedure Calling (RPC) that allows one application to initiate or “call” a function inside of an application on a remote server. Our Drupal site can communicate with an application on a remote server and call a function in that application. For example, we might want to make our Drupal website call and interact with our Flickr photo gallery, or we may want to take all of our Drupal home page content and push it over to our Facebook account. We can do both of these actions using the web service protocols.

XML and web services

As mentioned above, the base foundation for web services is a protocol or code called XML. For our Drupal site residing on our server, to talk and interact with a website or application on another server, we need to use XML, which is a language commonly understood between different applications. Our site and server understands XML as does the application we want to communicate with. We can do this over the standard HTTP protocol for website communication, as HTTP is the most standard protocol for Internet communication. The reason we use XML for communication between the applications and the sites is because XML replaces the proprietary function (whether the function is in RPC or another programming language or interface) and formats it into the standard XML code format. This allows applications to understand each other easily.

An analogy to this is: if we have two people, one from Germany and the other from France, speaking to one another, and neither person knows the other’s language but both of them know English, then they must speak in English, as it’s a language they both understand and can easily communicate in. It’s a similar situation when XML is used to translate a web service’s function into a commonly understood format.

So first we need to send the function call to a remote application. Our calling application or website creates the XML document that will represent the programmed function we want to execute. The XML is then transmitted over HTTP to the remote application and it can then be interpreted and understood by the remote application. The remote application then executes the function based on the XML formatting.

Some examples of web service’s methods are SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language), XML-RPC (XML Remote Procedure Call), JSON (JavaScript Object Notation), JSON-RPC, REST (Representational State Transfer), and AMF (Action Message Format). We are not going to look at these interfaces in detail now. For now, it’s helpful for us to understand that these protocols and platforms exist and that our Drupal site can provide web services to other applications via these multiple interfaces and platforms.

Here’s a diagram that outlines a simple web service request and response. This is a request sent from our Drupal site (client) over HTTP to an external server to request data. The data exists on the server (remote) in the form of a URI (Uniform Resource Identifier) item. The response is sent back to our Drupal site through XML.

The REST protocol

Let’s look briefly at one web service protocol and technology, and define it. As mentioned before, there are many technologies you can use to implement web services. REST (Representational State Transfer) is one such technology. The reason REST is a preferred technology within the web development and Drupal community is due to its flexibility and standards. REST allows us to do the following when we initiate a web service using its protocol:

• Use a standard method such as XML as our message format
• Send the message over standard protocol such as HTTP
• Provide or connect to specific resources where each resource (image, document, page, and node) is given a unique resource identifier (a URI)

We can take this concept and try it out on our Drupal site by writing some PHP code that makes an HTTP request to another web application resource. For example, we may want to make a call to a Picasa photo gallery and feed a select number and type of photos back to our Drupal site and display the photos in a Drupal node on our site. The request targets this specific resource by making a GET request to the URI of the resource. The application we are communicating with sends a response back to us in XML format. That XML can then be integrated into our Drupal site using a module, for example. The request might be made to a user’s Flickr or Picasa photo gallery. The request gets returned to our Drupal site as XML and we parse this XML into our Drupal site and the user’s photos or gallery then get displayed on our site.

This is just one protocol example.

Greg Hines of pingVision provides a good introductory resource on REST and Drupal in the document titled RESTful Web Services and Drupal. The document is available on pingVision’s website as a PDF download from: http://pingvision.com/files/restful_web_services_and_drupal.pdf

Standards compliance

As discussed in the REST protocol’s example, web services and Drupal’s use of web services follow specific standards. In order to maintain as much interoperability and flexibility as possible, all of the protocols used respond for the most part using XML as the standard response mechanism and format.

Additionally, all the communication between services, in our example between a client and a server, happens over HTTP (the standard web protocol). This is a uniform protocol that is used for transport and communication of the service. All transports take place uniformly using GET, POST, PUT, and DELETE requests, for example.

The HTTP requests are stateless, meaning that the request over HTTP happens once at one given moment and is isolated from all other activated requests. So the request stands alone. If it succeeds, it gets a response. If it fails, it gets no response from the server or application it’s communicating with. The request can be repeated an infinite number of times.

Finally, all of the resources we try and access are those that we are sending to another application using a unique resource identifier (URI) to identify and define what they are. So images on our site have unique identifiers as well as those residing in another web application. Each of these unique identifiers allows for addresses or locations for each node or file in question. So each resource in a web service’s communication has an address. Each resource has one URI and each address has one URI. Some examples of this would be the following locations on my Drupal site:

• http://variantcube.com/
• http://variantcube.com/recommended-drupal-resources
• http://variantcube.com/node/68
• http://variantcube.com/search/node/podcast
• http://variantcube.com/rss.xml

Another reason we want to be standards compliant, when writing or working with web services, is for simplicity. We do not need any special tools to program web services as long as we follow these standards. We can use the web application modules and PHP, and stick to these coding standards and protocols.

Why are web services useful?

Web services are useful for a number of reasons, especially when it comes to Drupal and Drupal’s relationship and interaction with other web content management systems and applications. The web has a huge number of web applications, so web developers and content developers can pass their content to the web browsers and make it available to the web visitors. This is why the Internet is useful to us. We can go to a website and view the content. Whenever we do that, we’re looking at content that is proprietary to a specific web application. In Drupal, our content is in the form of nodes, for example. We may want to share these nodes with other websites that are non-Drupal, such as a WordPress-powered site.

Web services are useful because they present us with an architecture where a resource on a site (an image, textual content, such as a node ID or block ID, a video or audio file) is given a unique identifier. For example, in Drupal, every node has an ID. Every file you upload to a Drupal site also has a unique path to it.

This is extremely useful since all applications share this common semantic standard. We name things similarly on all of our web applications. We can then leverage this by writing code in PHP, for example, the one that calls these resources. The application server that houses the resource then responds to our request using an XML document.

Why use web services in Drupal?

With web services, we can take our Drupal content and share this content with other web applications and, essentially, with the web at large. Our content is no longer just our content and it is not specific to our Drupal website. It can be shared and integrated. Drupal’s codebase is PHP-based and many of the popular web applications being used today, including WordPress, Joomla!, and Flickr, are also PHP-based. So we have a common programming language we can work with and use to integrate these applications.

Here are some concrete examples. Perhaps your Human Resources Department wants to integrate its job postings and applications with another web application such as Monster.com. Web services can allow this to happen. Your office’s payroll department may want to connect to its bank account in order to pass data from the payroll reports over to its bank reporting mechanism. Web services can allow this to happen. You may want to take all of the photos you upload to your Drupal site in image galleries built with the Views module, and take these photos and send them to Flickr so that they automatically show up in your Flickr account or on Flickr’s public site. Web services can make this happen.

This leads to another advantage of using web services with Drupal and why we would choose to use Drupal in the first place. Instead of having to upload our photos twice—once to our Drupal site and then repeating the procedure to our Flickr site—web services allows us to upload the images to our Drupal site once and then automatically send that data over to Flickr without having to upload one (or even a batch of images) again. It saves us time and speeds up the entire process of generating web-based content.

Additionally, there may be applications we want to use in our Drupal site, for example applications where we want to consume content without having to code again. We can just reuse these applications using the web services protocols and get this application content into our Drupal site. So we can consume web services. Examples of this would be converting currency on our site, feeding weather reports and other weather data into our site, feeding natural disaster scientific data into our site from services that provide it, feeding language translation services, feeding music podcasts, and more. Instead of having to reprogram this type of content, we can grab it from another web application and show it automatically on our site using web services

Simply put, this opens up a method of easily sharing data and content resources between applications and machines that are running on different platforms and architecture. We have opened up a gold mine of capabilities here because we can talk to applications that run different software from our Drupal site and on different computing platforms.

How Drupal uses web services

Drupal can use web services following any of the protocols mentioned earlier, including XML-RPC, REST, and SOAP. Drupal can consume web services by requesting data from other web applications using RSS and XML-formatted requests. As a web developer, you can write your own service code in Drupal using PHP. You can also use the Services module as well as other service-specific contributed modules to create these web service requests. In this next section, we’re going to look at both these examples. First, we’ll see how Drupal works as a service consumer, where basically it is a client requesting data from an external server.

We’ll also look at how Drupal can provide services using the Services module, RSS, AMFPHP, and XML-RPC.

Drupal as a service consumer

Let’s outline some brief examples of how Drupal consumes content and data from other web applications, including Mollom, Flickr, and Facebook.

You can configure your Drupal site to consume various web services by using contributed Drupal modules for each specific task or application you are trying to consume. Drupal can consume services from applications that will help your website prevent spam, integrate photos, integrate taxonomy and tags, and enhance your Drupal free tagging and autotagging abilities, and integrate with applications such as Facebook and Twitter.