Rest(ful) Services

When communicating this to a computer there are different characteristics. The formatting is not important but the structure is important.

Currently we are using Drupal as middleware for our app. We were going to move our website to Drupal but decided to go a different way but we had already setup Drupal to drive our App. This actually gave us an advantage. We had a site that we can tailor our content for the app and another for the web.

Recently we are rewriting our app and rewrote the services to speed things up. Initially we used the services module and the views plugin to feed the raw json similar to what we would use for the web site. The services would present a list of node numbers and you would use the services module to fetch the details of the node. When we asked for suggestions from the app developers they suggested providing all the content in one service call, this would be faster. I started looking at the views plugin and realized that we could use the Relationships portion of the views module to provide all the content not just the node number. I also realized we could provide only the fields we wanted and name them what we wanted. This cleaned up much of the of Drupalisms, in the json.

So we now use the Services Module and the Views Services module, and feed everything through Views. I even created a node view that cleans up the json of a node leaving out the Drupalisms.

After Drupalcon I looked into the RestWS module. The developer of this module is writing the Services for Drupal 8. It does clean up much of the Drupalisms of presenting an Entity, but it seems to lack a services module plugin where you can define the fields more completely.

When I get a chance the next step is to combine the fields that make up my body field so that I can present body field in the service, this eliminates the need to communicate the fields that make up the body of the content.

Hopefully before Drupal 8 is released or shortly there after a views plugin can be included in the services. This is a handy feature, also being able to define the fields in the service better would be a great help of building a killer service provider.

Lacking in the whole services arena (Apps, node, Angular...) is a good back end server that can manage your content. Drupal can do this in a great way, we need the tools to build a great service provider and we can fit into the next infrastructure.