REST is a beautiful thing. REST is an architectural style. Many public APIs are designed with a REST-style, as opposed to patterns like SOAP, WSDL, etc. Let’s see how simple it is.

GET     ../resources/
POST    ../resources/
GET     ../resources/{item_id}
PUT     ../resources/{item_id}
DELETE  ../resources/{item_id}

The beauty is in the abstraction. Not only is it less verbose than alternative patterns, it relies on HTTP protocol. HTTP requests require a method type, and REST APIs leverage this standard. You don’t have to duplicate that determination by creating a unique route for each method. The routes are already unique by how they are requested.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. – Dr. M. Elkstein, Learn REST

What difference does this make, you might ask. I would say much. The abstraction of the singular route for a resource with CRUD operations allows for cleaner implementation in the consumer – the entire reason the API exists – to provide an interface for a client to talk with the service. If you’ve had to work with a non-RESTful API you may empathize with me.

Working with REST

Backbone.js provides a good example of the abstraction you can get. Backbone expects a RESTful API. If the API you’re working with isn’t RESTful, you’ll have to make changes to Backbone.sync in order to make it work. Here’s an example of some Backbone code:

var TodoModel = Backbone.Model.extend({
    urlRoot: '/todos'
});

var TodoCollection = Backbone.Collection.extend({
    model: TodoModel,
    url: '/todos'
});

Create (POST)

With a RESTful API, Backbone doesn’t need any more information to be able to create, read, update or delete todos. This is what creating a new todo item looks like:

var newTodo = new TodoModel({ description: 'Make my API RESTful' });
newTodo.save();

Backbone knows that you are creating a new todo, so it will send a POST request to that model’s root url with the corresponding data.

POST ../todos

Similarly if you are updating an existing model, Backbone will PUT accordingly:

PUT ../todos/{todoId}

Working without REST

If you have to work with a non-RESTful API, what problems might you run into?

At worst, you can’t easily create these abstractions for your resources represented on the client-side. You end up having to write boilerplate code that’s slightly different per resource (potentially – it depends on how the API is structured).

When I’ve had to work with non-RESTful APIs, I have generally avoided frameworks like Backbone or Angular that can be opinionated about protocol. Which really sucks, because I’d rather use a well-organized and opinionated framework.