REST from scratch

This is the first post on a series of examples on how to use Rails and Restfulie on the server side and Restfulie and Mikyung on the client side to create REST based architectures.

On this 10 minutes video you will learn how it is possible to make several representations of one resource available on the server side (xml, json, atom and so on) and one line of code access and parse it on the client side.

This video shows how to access those basic REST api’s as Twitters, CouchDB which are based on http verbs and multiple URIs. The following videos shall demonstrate how to access more advanced REST API’s.

If you have any questions, join us at our mailing list.

Scaling through rest: why rest clients require cache support

It’s common to find developers struggling with their clients browser’s cache and proxies in order to get their application running as expected: some of them actually view cache options as a bad thing.

Actually http caches presents a few advantages, being the two most important amongst them all the ability to serve more clients at the same time without buying more expensive hardware (or horizontally scattering your system) and avoiding excessive bandwidth consumption where it can be saved or it is expensive.

A well known tutorial on how web caches work
was written by Mark Nottingham. Mark has also been involved with the Link header specification and developed Redbot, a clever machine that inspects your pages to avoid cache related issues you might be facing or improve your application scalability: and its everything connected to rest architectures.

Linked data is the basis for HATEOAS systems while http cache supports higher scalability using such architecture.

Imagine a theoretical scenario where a huge content provider application contains hundreds of thousands of articles that are frequently accessed in your country. Such application might have a few pages that change often, while others do not.

By adding a simple “Cache-control” header to your page, all existing cache layers between you and your client monitor will hold the resource representation in memory for one hour:


Cache-Control: max-age=7200


In Restfulie (Rails) it can be achieved by providing some cache information to your resource:


class OrdersController < ApplicationController
cache.allow 2.hours
end


Now there can be three cache systems leveraging from such header example.

The browser’s cache will use the previously retrieved representation while it does not expires, and might use it even if its expired and you did not provide the must-revalidate option. This will save you bandwidth and server cpu consumption.

A cache proxy situated within the users network, or anywhere between the server and the client machine, will serve the previously retrieved representation, saving you bandwidth outside your network and server cpu consumption.

A reverse proxy can cache the representation within the server’s network and save cpu consumption. This approach has been widely adopted in order to share cached representations amongst different consuming applications/users.

All these three savings are actually reverted in a easier to scale application, you did not need any paid middleware, any fancy stack or load balancers, although they might help: it saves you complexity, time and money.

There is much more you can do with cache headers (Last-Modified, ETag and so on) and REST libraries should make it easy to use them, appart from supporting local caches.

Finally, in syndication based systems, or in any other heavy machine-to-machine communication based one, a local cache might not be able to handle the large volume of caching hits. In such systems, it is a common approach to use distributable cache systems, and Restfulie allows you to use your own cache provider.

For example, a distributed cache like Memcached could be used by simply implementing three methods:


class MemcachedCache

def put(url, request, response)
# save it into memcached
end

def get(url, request)
# retrieves from cache, if available
end

# optional implementation
def clear
# clears the cache
end

end
Restfulie.cache_provider = MemcachedCache.new


Most used http clients implement low level features such as handling response and requests on your own, processing only the basic request headers.

The difference between http client libraries and rest client libraries is that the second should implement further http api processing, while the first allow access to the previously mentioned low level api.

And both because cache is part of the HTTP api and one of the key issues that made the web scale as we know it, Restfulie required such support out of the box (along with etag, last-modified and 304).

Not only one write less code to process the responses, but one leverages his client and server applications.

Note: I am moving my posts to our company’s blog, the next post will be just an announcement. Comments can be made either here or there.

When should I start a REST initiative

Restfulie’s release, centered on hypermedia support, got a lot of attention back to not letting go the HATEOAS idea and the old question arrives again: is it worthy to invest money or time building a fully REST system in my company?

A full REST architecture imply in many choices that some prefer to leave out, but it is interesting to see how people reacted to REST in the last few years.

Using google insights, the first thing to note – a biased query due to the selected keywords? – a continuing increase of interest in REST since 2004 in the programming area.

Surely, this can not be accepted as a single ‘soa is dead, long live rest’. In this result for the query, red means ‘soa’ and blue means ‘rest’.

A second search including ‘web services’ and ‘web service’ shows a decline for such words. For those who do not consider REST as a web service due to the general notion of WS being related to SOAP and WS-stacks, this is a positive aspect. The following result contains green and yellow meaning ‘webservices’, blue for ‘rest’ and red for ‘soa’.

if you compare searches for ejb, soap, corba and rest (blue is rest):

Finally, comparing those technologies to the growth of programming searches, rest is the only one whose growth is bigger than programming searches average:

If you are looking for a contemporaneous architectural style which is growing in its adoption, google seems to point you to REST. This information gives stronger hope to those who are putting their time, money or energy into REST architectures: they might have picked a good path.

A technology evolves faster as more people start using it. Although there is a long way to go with REST and its hypermedia features, it’s the only line going up.

When friends and clients ask if its time to try and learn it… definately.

note: this post is not about rest being good, or better than any other solution compared, just a collection of interesting outcomes from developer’s searches. Remember: there is no silver bullet.