I’m a C# developer and here’s my TOP 10 RESTful Principles.

Why RESTful is still awesome

Given the changing internet landscape, RESTful gives us a set of principles to work with when building a modern distributed system.

Services now need to reorient their architecture to account for the rise of devices and cloud computing.

The rise off devices

Once upon a time it was acceptable to build a system for a set of constrained devices and a single operating system. Things have changed.

The client application is now king.

The rise of devices brings two major concerns into focus.

  • How to provide different ways of viewing and using the same data.
  • Cross platform collaboration (aka heterogeneous interoperability).

REST principles are closely tied to servicing the rise of devices.

Cloud computing

Cloud computing is a new way of hosting application. It’s surprising how cheap a server can cost.

Modern distributed systems needs to be built differently if they want to take advantage of cloud computing.

Smaller cheaper nodes doing simpler work makes this possible. The significance of scalability, reliability and service evolution are all close tied to REST.

My Top 10

– Principle Tag Summary
1. Hypermedia No need for a predefined contract. Hypermedia decouples the client from the server. Hypermedia makes it possible to rebuild a set of Uri’s without having to deal with changes on the client. Hypermedia allows the server to drive the discovery of resources and activities. A good example of hypermedia is HTML. The txt in HTML comes with a load of mean. HTML is full of additional attributes and placeholders for additional action meaning. For example, a Form comes with an Action attribute. Hypermedia allows us to add a new step in a workflow without an automated client being aware. “The client made an additional uri request because it was told to do that _next_…”. It’s excellent when a RESTful client only needs to know a single resource uri to get started.
2. Best friends with HTTP Web maturity. Http comes with great stuff. Content data, conditional get definitions, rich status codes, cache headers, Accept headers, verbs, authority tokens, query string parameters, non txt format data, location header. Treating the rules of http as a first class solution player makes things so much easier! Rest doesn’t try to reinvent the relationship management skills http has gained through maturity.
3. Stateless Let’s keep things simple and scalable. A single restful action really does live in its own little stateless world. It’s chatty. This means that each action can be dealt with independently. This makes it easier for it to be improved, updated and versioned. Without having to manage state, each server node is allowed to flake without catastrophic results. Not having to manage ‘who the client is’ on the server makes solution architecture so much more flexible.
4. Uniformity Let’s join with other RESTful players. Rest works well when it allows a system to become a player in a community of other services. It allows a service to be easily picked up by various devices that also depend on other RESTful services. Abiding by a uniform interface means we can collaborate.
5. Cross Platform You don’t need to be Microsoft to join the party. Um. Yeh. I think this one speaks for itself. Who wants to build a different way of dealing with different clients.
6. Single responsibility Keeping each resource action simple. Decoupling the server from the client and keeping each action simple makes it possible to more easily modify server/client workflows and expected parameters.
7. Network Caching Why pay for a caching solution when the Internet already does that? For requests not running across SSL, the ability to use the network to handle various caching opportunities means RESTful services can run on cheaper resources. Rest leans on the network benefits, it gets that stuff for free. It means some level of caching can be achieved outside the solution.
8. Visibility and Responsiveness When a client steps through a Workflow we can keep them updated with their progress. The Internet is made up of packets. The end of the bulk upload black box. Real-time feedback. It’s chatty and that’s an excellent thing. It keeps the implementation simple.
9. Maturity There are 3 levels of maturity before you can graduate with a RESTful certificate. To figure if a solution can be theoretically classified as RESTful there’s a guide. Level 0: The swamp of plain old XML. Level 1: Defining “Resources”. Level 2: HTTPVerbs. Level 3: Hypermedia.
10. External Representation Business logic & domain model flexibility. The ability to decouple domain model from external representation creates flexibility. The domain model can change. The domain model must change. What doesn’t change are the external facing Resource models. These are business focused and don’t change! There is a noisy separation. RESTful Resources exist on the internet and take on a life of their own.

Challenges

These top 10 RESTful principles add loads of great stuff but they do come at a cost.

  • A comprehensive hypermedia implementation is rarely achieved.
  • Thinking in OO or RPC terms inhibits RESTful design. It’s a different problem space. Classes and methods won’t help us here.
  • Building RESTful clients involves more work than a regular RPC client.

Terms

Term Description
RPC Remote Procedure Call. A way of thinking about a call to a distributed system that adheres to a design that is very common and does not adhere to RESTful principles. RPC is most likely more commonly used that REST. Perhaps RPC is more mature and perhaps out dated.
Workflow In this case we are refering to a client/server workflow that involves various requests in a sequence. E.g. imagine a process of signing up which involves more than one step…
HTTP Verbs OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT
REST Representational state transfer. A software architectural style.