Learning to REST

July 16, 2014

Blog | Development | Learning to REST
Learning to REST

The word “REST” has become something of a buzzword in software developer circles. It’s an architectural style (REpresentational State Transfer) that allows programming languages and development platforms to pass data back and forth over the web without complex protocols or a lot of overhead.  The simplicity and lightweight nature of REST make it a great tool for a lot of web projects.  But… old habits die-hard.

I’ve been searching for good code to learn from and I’ve noticed something: programmers are treating REST like it’s a new form of MVC (ASP.Net Model-View-Controller framework), or just another server-side implementation of AJAX (Asynchronous JavaScript And XML). Worse yet, they’re treating it like a new flavor of WCF (Windows Communication Foundation). It’s related to all of those things, but it isn’t those things.

In MVC, you name your actions as part of the URL, and you rely primarily on HTTP’s GET and POST verbs. So you’d GET someurl/user/dan and the framework would dish up some HTML that represents the “dan” user.  To update data to the framework you might have a method called “save” you could invoke by POSTing to someurl/user/dan/save.  In this scenario, any “action” that must be performed on the “dan” user would be specified as a method of the “user” controller.  You might end up with a wide variety of method names, such as /GiveaCookie or /ShareaBeer.  Each controller will be unique.

That’s fine, but a REST API generally doesn’t and shouldn’t respond with HTML. While MVC is targeted towards controlling the user interface, REST targets the database.

One of the greatest strengths of REST is how well it integrates the HTTP specification with the normal every-day things we do on the web. 

In particular, it leverages more of the HTTP verbs than just GET and POST.  It uses PUTand DELETE as well.  For database-oriented people, that translates to CRUD (Create, Read, Update, Delete).  The PUT verb is the Update call, which means the POST is now strictly for creating entities in the database.  A short mental hop leads to this conclusion: your REST controller should generally have no more than 4 methods, and their names are POST, GET, PUT, and DELETE.  In this respect, every controller will be the same.

In future posts, I’ll explore how this consistency can be used to great affect using various technologies including Jquery, Angular, .Net MVC, and even, Node.js.

Are you building a REST API? Do you build routes to accomodate actions, or do you utilize as many of the HTTP verbs as possible? Send us a Tweet @GeekHive

Dan Clouse

Senior Developer
Tags
  • Development
  • JavaScript
  • Patterns & Practices

Recent Work

Check out what else we've been working on