Accelerating front end development

Accelerating front end development

This example illustrates how RESTx allows front-end developers to quickly and easily make their own data resources, without having to rely on the back-end server team for every new requirement.

Example scenario

Let’s say you are working as a front-end developer (JavaScript, HTML, CSS, etc.) on some web-application project. You are part of a larger team and thus a different group is implementing the back-end services. You need to display all sorts of information to the user and AJAX is used to fetch the data for display. Maybe you are using a JavaScript library like Dojo, Ext JS or jQuery, which provide convenient functionality for data retrieval. All is well until you realize that every time you need a new data resource you have to discuss this with the back-end team. Your request may go on their todo list and if you are lucky it becomes available to you with the next iteration. In the meantime, you lose time, need to work with fake testing data and see your deliverable jeopardized by the inability of the back-end team to deliver in a timely manner if they feel for some reason that other things are more important.

In your project you might utilize very general query interfaces to all of your data, so you can specify the query you need by sending it to the server in the URI or the message body. There are problems with this approach, however: For one, that query you are talking about may contain query parameters that are not intended for public viewing. Those queries can leak anything from access credentials to databases, to hints about the internal structure of your data, which you’d rather keep private. They are now showing up in your client code and – possibly worse – in server, proxy and firewall logs at every stage between the client and the back end. You may also break caching schemes along the way, thus making your system less scalable. Furthermore, you are now closely coupling client side code with particular server-side implementation details, which means that a simple change on the server side now may result in changes all over your client code. Besides, sending full-blown queries in the URI or message body (using POST or PUT to get query results?) is not particularly RESTful, is it?

Wouldn’t it be nice if you could just create your own data resources on the server, which completely hide query details behind a simple, easy to use URI and which can be dealt with in a RESTful manner? Where the data is easily cacheable? Something that at the same time insulates client code from implementation details and changes on the server? In other words: You, the front-end developer, should be able to tell the server: “Create me a new RESTful resource, which represents the following query… and give me a simple URI as handle for that resource.”

This is exactly what you can do with RESTx.

Concrete example: Screen scraping

Consider an actual example: Assume you need to display some weather information in your application. Your JavaScript cannot directly access a public weather API due to JavaScript’s same origin policy. And your back-end team doesn’t have time right now to implement a data service for you, which encapsulates access to such an API. But fortunately, on your RESTx server there is a screen scraper component installed. In fact, an example screen scraper component, which specializes in weather data, ships with the RESTx distribution. It’s easy to adapt that simple example component to other needs. But for you as the front-end developer in our scenario, this weather screen-scraper component is just perfect.

RESTx is RESTful, which means you can explore the entire system, all the available components and resources, all their documentation and parameters merely by following links. You discover the component and click on its URI. This is what you see:

Information about the weather scraper component

Every component is self documenting. You can see the name, the various parameters it needs, and so on. There is even a link to further documentation. Let’s click on that:

Documentation for the weather scraper component

There, the author of the component was kind enough to provide you with some detailed instructions on how to configure the screen scraping. Now then, let’s go back to the component’s main page and click on the ‘[ Create resource ]‘ link. You can see a form, prompting you to provide values for all the required parameters. Here you see that form partially filled out, with the right tags to scrape the weather information from weather.com:

Creating a new weather scraping resource

Note that you are specifying your own name for the new resource and also your own, specific description. This allows you and your fellow front-end developers to view the resource in a context that makes sense to you, de-coupled from any server-side considerations. After submitting the form, RESTx lets you know if the resource creation was successful:

Resource was created, new URI is shown

You also see the new URI of the resource: “/resource/SF_Weather”. Click on it. You get an overview of this particular resource. This is now much smaller than what you saw for the component. All the details about screen scraping are hidden. You only see the information that is needed to use the resource:

Information about the new resource

Under ’services’ there is a URI for “/resource/SF_Weather/current”. This is a link to a sub-resource and the one that actually will give you the data that you want: The current weather in San Francisco. When you click on that link, you see this:

The new weather resource data

There it is! The current weather conditions in San Francisco, hidden behind a simple, easy to use URI. When you hit that URI, RESTx retrieves the stored parameters you provided when you created this resource. It then invokes the WeatherScraper component and applies those parameters, resulting in the server retrieving a page from weather.com, extracting the weather data and returning the result. But none of that is of any importance to the user of this URI.

In fact, let’s say your back-end team finally gets around to implement your request. They write a RESTx component to access the actual API from weather.com or any other weather service. Now provide a proper set of parameters to that component to retrieve the weather information for San Francisco. Specify the same name for this new resource and it will be created with the same URI: “/resource/SF_Weather”. Now all your client applications continue to work as if nothing happened. That is the advantage of encapsulating more complex data access scenarios and queries behind their own dedicated URIs.

The same data, just different: JSON

By now you will ask: “Getting weather information into a browser is nice, but I need to retrieve it with JavaScript and do some work on this data!”. Sure enough, RESTx can handle this situation. If you insert Accept: application/json as a header into your HTTP request, RESTx returns the very same information to you, but formatted in plain JSON, which JavaScript deals with naturally. This is what you will get:

{
    "Condition": "Partly Cloudy",
    "Temperature": "60° F",
    "Wind": "Wind: From SW at 15mph"
}

Conclusion

Screen scraping is of course not the only application here. You can imagine components that provide access to databases, special APIs and all sorts of data sources. RESTx’s RESTful resources are not just read-only. If implemented in the component, you can also update and create entities via PUT / POST. We believe that RESTx is the fastest way to create RESTful resources in your organization or in the cloud. It gives you as front-end developer a greater degree of freedom, allows you to use safer URIs and generally improves the speed and agility of your team: Let the back-end developers focus on programming access mechanism for data, while you as the front-end developer or user can focus on exactly which data you want.

 

Next steps