With the evolution of Headless Drupal, Drupal is moving towards on being a preferable content storage to serve the data. But how is Drupal when being used as a Front end consuming remote data instead of proving it?

In one our recent project we have to achieve the same. Drupal is being used to display the remote data which is being provided by RESTful APIs. The catch was the data that was being consumed should not be saved in the Drupal database. So it was purely used just to display the data. Not only that we need to use the consumed data in views, and panels.

There are a few ways of doing this. One being using drupal_http_request function to consume the data and use it. But that would require a lot of customizations and in the long run would be very difficult to maintain.

In comes Web Service Data module

According to its documentation:
“Web Service Data is a collection of modules allowing you to interact with web services using entities and fields in Drupal.”

It was a perfect match for our requirement. The module will consume the data from Web Services and display it without saving any of it in the database. Plus it have fields, views and panels integration. So it was a win win situation all together.

So I am going to discuss how to use the Web Service Data module to consume Web Services and use them just as normal fields.

Enable the following modules:

  1. Web Service Data – Parent module to handle all the web services.
  2. Web Service Data Configuration – It enables to add the web service configuration from where we will fetch the data.
  3. Web Service Data Fields – Attach the power WSData module to fields.
  4. Web Service Data Fields Views Handlers – View handler for fields which are powered by WSData module.
  5. Web Service Fields Storage – Storage controller for fields to load the data.
  6. WS Data Demo – A demonstration on how to the module in action.

Once enabled if you go to “admin/structure/wsconfig/type” you will see a configuration type being added by the demo module.

In the Web Service Configuration section we define the endpoint of the service.

Next we go to “admin/structure/wsconfig”. The demo module has added a configuration for the type prescribed above. The configuration defines what CRUD operations for the service along with the method for it.

The demo module have also added a content type “Linked Data” with a title field and body field. The body field is provided by Web Service Data Fields module. In “admin/config/services/wsfields_storage” you can see the field being declared and configured to fetch data from the web service configuration.

So, we create a content for Linked Data. In the form we just need to enter the title. Lets say we enter “Drupal”. Once the content is saved you will be taken to the node page where the body of the content will be filled up by the Drupal wikipedia page.

Now let's use this module to fetch some remote data and publish it on our Drupal site. For this lets say we have an endpoint called http://examplesite.com/api/article/{article_id} which gives us details about an article.

  1. Go to “admin/structure/wsconfig_types” and add a Configuration type.
  2. Next we add a web service configuration for the type. We select the EventCampus Articles configuration as our endpoint.
  3. Add the required fields you want to fetch from the web services in “admin/config/services/wsfields_storage”. You can select what type of data you want to fetch and to which entity you want to attach the data. In the Web Service Remote Data Key you need to specify which field will hold the argument to the web service call. Like in our case title was the holder for the remote article_id argument.
  4. Now when we create a content of type article we can see the data pulled from the remote web service and being displayed in the node page.

This data can be used like default node fields in Views or Panels without any problem.

Currently once a few types of fields can be handled using the WsData module. But you can easily create handler for other fields which are not there like email, links, etc...

Conclusion, it’s a great module when we want to display data fetched from web services with saving in Drupal database. It comes packed with a good API system which we can extend to use it even in custom entities.

 

comments powered by Disqus