The SQL Developer’s Guide to REST Services

by Kenneth Lange  

This is a practical guide (with lots of examples) to help SQL developers quickly learn the basics of RESTful Web Services.

Data Storage: Tables versus Resources

Both SQL and RESTful Web Services are centered around data.

In SQL, data is normally stored in tables, but in REST Services it is stored in resources.

For example, in a database you could have a customer table:

SQL> SELECT * FROM customer;

ID FIRST_NAME LAST_NAME OCCUPATION
-- ---------- --------- -----------
1  Luke       Skywalker Jedi Master
2  Leia       Organa    Princess

In REST Services, you would have a /customers resource instead of a customer table.

For example, if you want to get all customers (similar to the SQL statement above), you do it like this:

GET /customers

The response to this request would be a JSON array with an object for each customer:

[
  {
    "id": 1,
    "firstName": "Luke",
    "lastName": "Skywalker",
    "occupation": "Jedi Master"
  },
  {
    "id": 2,
    "firstName": "Leia",
    "lastName": "Organa",
    "occupation": "Princess"
  }
]

CRUD Operations

The HTTP methods, which are used for RESTful Web Services, map neatly to the common SQL statements:

CRUD Operation HTTP Method SQL Statement
CreatePOSTINSERT
ReadGETSELECT
UpdatePUT PATCHUPDATE
DeleteDELETEDELETE

The following sections will explain each of them in more details.

Create

To create a new customer, you use the INSERT statement in SQL. For example:

INSERT INTO customer (first_name, last_name, occupation) VALUES ("Han", "Solo", "Smuggler");

In REST, you create a new customer by sending a POST request with the new customer as a JSON object:

POST /customers

{
  "firstName": "Han",
  "lastName": "Solo",
  "occupation": "Smuggler"
}

Read

To read data in SQL, you use the SELECT statement.

For example, to get a complete list of all customers, you simply call:

SELECT * FROM customer;

The corresponding HTTP command is GET, which you can call like this to the same result:

GET /customers

If you want to lookup a specific customer using the primary key, you would do it like this in SQL:

SELECT * FROM customer WHERE id = 2;

In REST you would append the id to the REST resource:

GET /customers/2

But what if you want to lookup something using a non-primary key?

In SQL you would just add a WHERE clause to your SELECT statement:

SELECT * FROM customer WHERE first_name = "Luke";

In REST, you append a query parameter to the GET statement:

GET /customers?firstName=Luke

Note: The specific query parameters available depend on the REST service you are using.

You may want to limit the number of fields returned by a query, because you don’t need to display all the fields, or because you want to improve performance.

In SQL, you just specify what columns should be returned:

SELECT first_name, last_name FROM customer;

In REST, you request a partial response:

GET /customers?fields=firstName,lastName

Note: Partial responses are not available in all RESTful Web Services, but usually in those where performance is key. For example, mobile apps that may need to operate in an environment with limited bandwidth.

Update

If you want to update all columns on a customer via SQL, you use the UPDATE statement:

UPDATE customer
   SET id = 2, 
       first_name = "Leia", 
       last_name = "Organa", 
       occupation = "General"
 WHERE id = 2;

In REST, you do the same by using the PUT method:

PUT /customers/2

{
  "id": 2, 
  "firstName": "Leia", 
  "lastName": "Organa", 
  "occupation": "General"
}

But what if you only want to update some of the fields?

In SQL you simply limit the fields to those you want to update:

UPDATE customer
   SET occupation = "General"
 WHERE id = 2;

In REST, you use the PATCH method:

PATCH /customers/2

{
  "occupation": "General"
}

Note: The difference between PUT and PATCH is that PUT must update all fields to make it idempotent. This fancy word basically means that you must always get the same result no matter how many times it is executed. This is important in network traffic, because if you’re in doubt whether your request has been lost during transmission, you can just send it again without worrying about messing up the resource’s data.

Delete

If you need to delete a customer, you use the DELETE statement in SQL:

DELETE FROM customer WHERE id = 2;

Similar, in REST you use the DELETE method:

DELETE /customers/2

That’s it! This is my attempt to map the key concepts in RESTful Web Services to the corresponding key concepts in SQL. If you understand these, you already got a pretty good headstart towards learning REST Services.

Of course, there is more to REST Services than what has been shown in this short post:

  • If you want broader introduction, check out: What are RESTful Web Services?
  • If you want to move beyond CRUD and model business workflows in REST, check out: Modeling Workflows in REST APIs.
  • If you need to design a RESTful Web Service, use this checklist to make sure you haven’t missed anything.
  • If you want to see how REST services are actually used in a modern web app, check out my Oracle JET post.

Thank you so much for reading!

Share this post:

Facebook Twitter LinkedIn Email



Subscribe to my blog

Just enter your email below and press the button:


Related Posts: