Top REST API Best Practices

Top REST API Best Practices

In this post, my goal will be to explain REST as clearly as possible so you can clearly understand when and how to use it, as well as what it is in essence.

In this post, my goal will be to explain REST as clearly as possible so you can clearly understand when and how to use it, as well as what it is in essence.

Many giants like Facebook, Google, GitHub, Netflix, Amazon, and Twitter have their own REST(ful) APIs that you can access to get or even write data.

But why all the need for REST?

Is it that good and why is it so prevalent?

Surely it’s not the only way to convey messages?

What is the difference between REST and HTTP?

Well, it turns out REST is pretty flexible and compatible with HTTP (which is the main protocol the internet is based upon). Since it is an architectural style and not the standard, it provides a lot of freedom to implement various design best practices. Did I mention it’s language agnostic?

In this blog post, my goal will be to explain REST as clearly as possible so you can clearly understand when and how to use it, as well as what it is in essence.

We’ll go through some basics and definitions as well as show off some REST API best practices. This should give you all the knowledge you need to implement REST APIs in any language in which you prefer to code.

If you are not that familiar with HTTP, I recommend reading our HTTP series, or at least part 1 of it, so you can digest this material more easily.

So What Is REST Essentially?

REST (Representational State Transfer) is an architectural style founded by Roy Fielding in his Ph.D. dissertation “Architectural Styles and the Design of Network-based Software Architectures” at UC Irvine. He developed it in parallel with HTTP 1.1 (no pressure).

We use REST primarily as a way to communicate between computer systems on the World Wide Web.

Is REST Bound to HTTP?

By definition, it’s not. Although you can use some other application protocol with REST, HTTP has remained the undisputed champion among application protocols when it comes to the implementation of REST.

REST and HATEOAS support

HATEOAS or the **Hypermedia As The Engine Of Application State **is the important feature of every scalable and flexible REST API.

The HATEOAS constraint proposes that the client and server communicate entirely utilizing the hypermedia.

There are several advantages to using hypermedia:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply

So it is clear that the HATEOAS was designed with durability in mind.

Here is how GitHub does it:

GET https://api.github.com/users/codemazeblog

Response:

{
  "login": "CodeMazeBlog",
  "id": 29179238,
  "avatar_url": "https://avatars0.githubusercontent.com/u/29179238?v=4",
  "gravatar_id": "",
  "url": "https://api.github.com/users/CodeMazeBlog",
  "html_url": "https://github.com/CodeMazeBlog",
  "followers_url": "https://api.github.com/users/CodeMazeBlog/followers",
  "following_url": "https://api.github.com/users/CodeMazeBlog/following{/other_user}",
  "gists_url": "https://api.github.com/users/CodeMazeBlog/gists{/gist_id}",
  "starred_url": "https://api.github.com/users/CodeMazeBlog/starred{/owner}{/repo}",
  "subscriptions_url": "https://api.github.com/users/CodeMazeBlog/subscriptions",
  "organizations_url": "https://api.github.com/users/CodeMazeBlog/orgs",
  "repos_url": "https://api.github.com/users/CodeMazeBlog/repos",
  "events_url": "https://api.github.com/users/CodeMazeBlog/events{/privacy}",
  "received_events_url": "https://api.github.com/users/CodeMazeBlog/received_events",
  "type": "User",
  "site_admin": false,
  "name": "Code Maze",
  "company": "Code Maze",
  "blog": "https://code-maze.com",
  "bio": "A practical programmers' resource.",
  ...
}

As you can see, besides the crucial information requested by the client, you can find a bunch of related hypermedia links in the response which lead you to other parts of the API you can freely explore.

What Does RESTful API Mean?

“RESTful” implies a few features:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply

So, the RESTful API is a service that follows these rules (hopefully) and uses HTTP methods to manipulate the set of resources.

But why do we need or use RESTful APIs?

Because they give us an easy, flexible, and scalable way to make distributed applications that communicate over the internet.

Can We Have Too Much REST?

Yes, you guessed it. Yes, we can.

There is even a phrase for the people that follow REST fanatically, as defined by Mike Schinkel.

A RESTifarian is a zealous proponent of the REST software architectural style as defined by Roy T. Fielding in Chapter 5 of his Ph.D. dissertation at UCIrvine. You can find RESTifarians in the wild on the REST-discuss mailing list. But be careful, RESTifarians can be extremely meticulous when discussing the finer points of REST, as I learned recently while participating on the list.
Too much of anything can be bad.

We need a bit pragmatism to make good applications and services. A theory is important to know and understand, but the implementation of that theory is what differentiates bad vs good vs excellent applications. So be smart, have the end user in mind.

So let’s look at some important points that make APIs “shine” and the lives of the users a whole lot easier.

Abstract vs Concrete APIs

When developing software we often use abstraction and polymorphism to get most of our applications. We want to reuse as much of the code as possible.

So should we write our APIs that way too?

Well, that is not exactly the case with APIs. For REST APIs, concrete is better than abstract. Can you guess why?

Let me show you a few examples.

Let’s look at two API versions. Is it better to have an API that has one /entities or an API that has /owners/blogs and, /blogpostsseparately?

Which one seems more descriptive to you as a developer? Which API would you rather use?

I would always choose the second one.

URI Formatting (Nouns, not Verbs): Good URL vs Bad URL Examples

Here is another REST API best practice. How should you format your endpoints?

If you use the software development approach you will end up with something like this:

/getAllBlogPosts

/updateBlogPost/12

/deleteBlogPost/12

/getAuthorById/3

/deleteAuthor/3

/updateAuthor/3

You get the point… There will be a ton of endpoints, each one doing something else. There is a better system for sorting out this mess.

Treat the resource like a noun, and the HTTP method as a verb. If you do it like that, you’ll end up with something like this:

GET /blogposts - gets all the blog posts.

GET /blogposts/12 - gets the blog post with the id 12.

POST /blogposts - adds a new blog post and returns the details.

DELETE /blogposts/12 - removes the blog post with the id 12.

GET /authors/3/blogposts - gets all the blog posts of the author with id 3.

This is a cleaner and more precise way to use the API. It is immediately clear to the end user, and there is a method to the madness.

You can make it even cleaner by using singulars instead of plurals for the resource names. That one is up to you.

Error Handling

This is another important aspect of API building. There are a few good ways to handle errors.

Let’s see how the top dogs do it.

Twitter:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply
{"errors":[{"code":215,"message":"Bad Authentication data."}]}

Twitter gives you the Status Code and Error Code with the short description of the nature of the error that occurred. They leave it up to you to look the codes up on their Response Codes page.

Facebook:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply
{
   "error": {
      "message": "An active access token must be used to query information about the current user.",
      "type": "OAuthException",
      "code": 2500,
      "fbtrace_id": "DzkTMkgIA7V"
   }
}

Facebook gives you a more descriptive error message.

Twilio:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply
<?xml version='1.0' encoding='UTF-8'?>
<TwilioResponse>
    <RestException>
        <Code>20404</Code>
        <Message>The requested resource /2010-04-01/Accounts/1234/IncomingPhoneNumbers/1234 was not found</Message>
        <MoreInfo>https://www.twilio.com/docs/errors/20404</MoreInfo>
        <Status>404</Status>
    </RestException>
</TwilioResponse>

Twilio gives you an XML response by default and the link to the documentation where you can find the error details.

As you can see, the approaches to error handling differ from implementation to implementation.

The important thing is not to leave the user of the REST API “hanging,” i.e. not knowing what happened or aimlessly wandering through the wastes of StackOverflow searching for the explanation.

Status Codes

When designing a REST API, you communicate with the API user by utilizing HTTP Status Codes. There are a lot of status codes, describing multiple possible responses.

But just how many should you use? Should you have a strict status code for every situation?

As with many things in life, the KISS principle applies here too. There are over 70 status codes out there. Do you know them by heart? Will the potential API user know them all, or will it once again result in googling stuff?

Most developers are familiar with the most common status codes:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply

By starting with these three, you can cover most of the functionalities of your REST API.

Other commonly seen codes include:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply

You can use these to help the user quickly figure out what the result was. You should probably include some kind of message if you feel the status code is not descriptive enough like we discussed in the error handling section. Once again, be pragmatic, help the user by using a limited number of codes and descriptive messages.

You can find the complete HTTP Status codes list, as well as other helpful HTTP stuff here.

Security

There is not much to be said about REST API security because REST doesn’t deal with security. It relies upon standard HTTP mechanisms like basic or digest authentication.

Every request should be made over HTTPS.

There are many tricks to improve the security of your REST API, but you must be cautious when implementing them, because of the stateless nature of REST. Remembering the state of the last request goes out of the window, and the client is where the state should be stored and verified.

Timestamping and logging requests can help a bit too.

There is much more to be said on this topic, but it is out of the scope of this post. We have a nice post on HTTP Security if you want to learn more about that.

REST API Versioning

You’ve already written your REST API and it has been very successful and many people have used it and are happy with it. But you have that juicy new functionality that breaks other parts of the system. The breaking change.

Never fear, there is a solution for that!

Before you start making your API, you can version your API by prefixing the endpoints by the API version: https://api.example.com/v1/authors/2/blogposts/13

This way you can always increment your API version number (eg. v2, v3…) whenever there are breaking changes in your API. This also signals to the users that something drastic has changed and they should be careful when using the new version.

Importance of Documentation

This one is a no-brainer. You could be the best API designer in the world, but without documentation, your API is as good as dead.

Proper documentation is essential for every software product and web service alike.

You can help the user by being consistent and using clear and descriptive syntax, sure. But there is no real replacement for good ol’ documentation pages.

Here are some of the great examples:

  • It enables API designers rather than to include everything they can in each response, to provide one thing properly and hypermedia links to related endpoints and thus decouple the design
  • It helps API evolve and mature more gracefully
  • It provides the user with the means to explore the API more deeply

There are many tools that can help you document your API, but don’t forget to add the human touch, only one human can properly understand another. For now at least (looking at you AI).

Conclusion

We went through many concepts of the REST API building and covered some of the top REST API best practices. These might seem a bit strange or overwhelming when served at once, but try making your own REST API. And try to implement some the REST API best practices you learned here.

Make the tiniest API possible and see how it looks. You’ll be surprised how well it can turn out by just following these few practices.

What is REST API? | Restful Web Service

What is REST API? | Restful Web Service

In this post "Restful Web Service", you'll learn: What is Web services, what is API, What is REST API, How REST works and Implementation of REST API

What is REST API? | Restful Web Service

A REST API defines a set of functions to process requests and responses via HTTP protocol.

REST is used in mobile application as well as in web applications.


Web Development with Rust - 03/x: Create a REST API

Web Development with Rust - 03/x: Create a REST API

Since Rust is a static typed language with a strong compiler you won't face many of the common pitfalls about running a web service in production. Although there are still run time errors which you have to cover.

Content
  1. HTTP Requests
  2. POST/PUT/PATCH/DELETE are special
  3. The Job of a Framework
  4. Creating an API spec
  5. Crafting the API
  6. Input Validation
  7. Summary

APIs are the bread and butter of how a modern and fast-paced web environment. Frontend application, other web services and IoT devices need to be able to talk to your service. API endpoints are like doors to which you decide what comes in and in which format.

Since Rust is a static typed language with a strong compiler you won't face many of the common pitfalls about running a web service in production. Although there are still run time errors which you have to cover.

HTTP Requests

When we talk about creating an API we basically mean a web application which listens on certain paths and responds accordingly. But first things first. For two devices to be able to communicate with each other there has to be an established TCP connection.

TCP is a protocol which the two parties can use to establish a connection. After establishing this connection, you can receive and send messages to the other party. HTTP is another protocol, which is built on top of TCP, and it's defining the contents of the requests and responses.

So on the Rust side of things, TCP is implemented in the Rust core library, HTTP is not. Whatever framework you chose in the previous article they all implement HTTP and therefore are able to receive and send HTTP formatted messages.

An example GET requests for example looks like this:

GET / HTTP/1.1
Host: api.awesomerustwebapp.com
Accept-Language: en

It includes:

  • GET: the HTTP method
  • /: The path
  • HTTP/1.1: The version of the HTTP protocol
  • HOST: The host/domain of the server we want to request data from
  • Accept-Language: Which language we prefer and understand

The most common used HTTP methods are:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE
POST/PUT/PATCH/DELETE are special

We are using GET every time we browse the web. If we want to alter data however (like using POST to send data over to another server), we need to be more cautions and precise.

First, not everyone is allowed to just send a bunch of data to another server. Our API can for example say: "I just accept data from the server with the host name allowed.awesomerustapp.com.

Therefore, when you send a POST to another server, what actually happens is the CORS workflow:

We first ask the server what is allowed, where do you accept requests from and what are your accepted headers. If we fulfill all of these requirements, then we can send a POST.

Disclaimer: Not all frameworks (like rocket and tide) are implementing CORS in their core. However, in a professional environment, you handle CORS on the DevOps side of things and put it for example in your NGINX config.
The Job of a Framework

We use the hard work of other people to create web applications. Everything has to be implemented at some point, just not from you for most of the time. A framework covers the following concerns:

  • Start a web server and open a PORT
  • Listen to requests on this PORT
  • If a request comes in, look at the Path in the HTTP header
  • Route the request to the handler according to the Path
  • Help you extract the information out of the request
  • Pack the generated data and HTTP StatusCode (created from you) and form a response
  • Send the response back to the sender

The Rust web framework tide includes http-service, which provides the basic abstractions you need when working with HTTP calls. The crate http-service is built on top of hyper, which transforms TCP-Streams to valid HTTP requests and responses.

Your job is to create routes like /users/:id and add a route_handler which is a function to handle the requests on this particular path. The framework makes sure that it directs the incoming HTTP requests to this particular handler.

Creating an API spec

You have to define your resources first to get an idea what your application needs to handle and uncover relationships between them. So if you want to build a idea-up-voting site, you would have:

  • Users
  • Ideas
  • Votes

A simple spec for this scenario would look like this:

  • Users
  • POST /users
  • GET /users
  • PUT /users/:user_id
  • PATCH /users/:user_id
  • DELETE /users/:user_id
  • GET /users/:user_id

Ideas and Votes behave accordingly. A spec is helpful for two reasons:

  • It gives you guidelines not to forget a path
  • It helps to communicate to your API users what to expect

You can tools like swagger to write a full spec which also describes the structure of the data and the messages/responses for each path and route.

A more professional spec would include the return values for each route and the request and response bodies. However, the spec can be finalized once you know how your API should look like and behave. To get started, a simple list is enough.

Crafting the API

Depending on the framework you are using, your implementation will look different. You have to have the following features on your radar to look out for:

  • Creating routes for each method (like app.at("/users").post(post_users_handler))
  • Extracting information from the request (like headers, uri-params and JSON from the request body)
  • Creating responses with proper HTTP codes (200201400404 etc.)

I am using the latest version of tide for this web series. You can add it in your Cargo.toml file and use it for your web app:

[dependencies]
tide = "0.1.0"

Our first User implementation will look like this:

async fn handle_get_users(cx: Context<Database>) -> EndpointResult {
    Ok(response::json(cx.app_data().get_all()))
}

async fn handle_get_user(cx: Context<Database>) -> EndpointResult {
let id = cx.param("id").client_err()?;
if let Some(user) = cx.app_data().get(id) {
Ok(response::json(user))
} else {
Err(StatusCode::NOT_FOUND)?
}
}

async fn handle_update_user(mut cx: Context<Database>) -> EndpointResult<()> {
let user = await!(cx.body_json()).client_err()?;
let id = cx.param("id").client_err()?;

if cx.app_data().set(id, user) {
    Ok(())
} else {
    Err(StatusCode::NOT_FOUND)?
}

}

async fn handle_create_user(mut cx: Context<Database>) -> EndpointResult<String> {
let user = await!(cx.body_json()).client_err()?;
Ok(cx.app_data().insert(user).to_string())
}

async fn handle_delete_user(cx: Context<Database>) -> EndpointResult<String> {
let id = cx.param("id").client_err()?;
Ok(cx.app_data().delete(id).to_string())
}

fn main() {
// We create a new application with a basic, local database
// You can use your own implementation, or none: App::new(())
let mut app = App::new(Database::default());
app.at("/users")
.post(handle_create_user)
.get(handle_get_users);
app.at("/users/:id")
.get(handle_get_user)
.patch(handle_update_user)
.delete(handle_delete_user);

app.serve("127.0.0.1:8000").unwrap();

}

You can find the full implementation of the code in the GitHub repository to this series.

We see that we first have to create a new App

let mut app = App::new(())

add routes

app.at("/users")

and for each route add the HTTP requests we want to handle

app.at("/users").get(handle_get_users)

Each framework has a different method of extracting parameters and JSON bodies. Actix is using Extractors, rocket is using Query Guards.

With tide, you can access request parameters and bodies and database connections through Context. So when we want to update a User with a specific id, we send a PATCH to /users/:id. From there, we call the handle_update_user method.

Inside this method, we can access the id from the URI like this:

let id = cx.param("id").client_err()?;

Each framework is also handling its own way of sending responses back to the sender. Tide is using EndpointResult, rocket is using Response and actix HttpResponse.

Everything else is completely up to you. The framework might help you with session management and authentication, but you can also implement this yourself.

My suggestion is: Build the first skeleton of your app with the framework of your choice, figure out how to extract information out of requests and how to form responses. Once this is working, you can use your Rust skills to build small or big applications as you wish.

Input Validation

Your best friend in the Rust world will be serde. It will help you parse JSON and other formats, but will also allow you to serialize your data.

When we talk about input validation, we want to make sure the data we are getting has the right format. Lets say we are extracting the JSON body out of a request:

let user: User = serde_json::from_str(&request_body);

We are using serde_json here to transform a JSON-String into a Struct of our choice. So if we created this struct:

struct User {
name: String,
height: u32,
}

we want to make sure the sender is including name and height. If we just do serde_json::from_str, and the sender forgot to pass on the height, the app will panic and shut down, since we expect the response to be a user: let user: User.

We can improve the error handling like this:

let user: User = match serde_json::from_str(&request_body) {
Ok(user) => user,
Err(error) => handle_error_case(error),
};

We catch the error and call our handle_error_case method to handle it gracefully.

Summary
  1. Pick a framework of your choice
  2. rocket is nightly
  3. actix is stable
  4. tide is fostered close to the Rust Core and also works on Rust nightly
  5. Know that there is no common CORS handling (yet). Recommendation is to handle this on the DevOps side (NGINX for example)
  6. After picking a framework, spec out your resources (/users: GET, POST etc.)
  7. Figure out how the framework of your choice is handling extracting parameters and JSON from the request and how to form a response
  8. Validate your input via match and serde_json

Thanks For Visiting, Keep Visiting. If you liked this post, share it with all of your programming buddies!

Why you should learn the Rust programming language

☞ The Rust Programming Language

☞ Rust Vs. Haskell: Which Language is Best for API Design?

☞ An introduction to Web Development with Rust for Node.js Developers

☞ 7 reasons why you should learn Rust programming language in 2019

Why you should move from Node.js to Rust in 2019

☞ Rust: Building Reusable Code with Rust from Scratch

☞  Programming in Rust: the good, the bad, the ugly.

☞  An introduction to Web Development with Rust for Node.js Developers

☞ Intro to Web Development with Rust for NodeJS Developers

☞ Introducing the Rust Crash Course

3 Frameworks for Building APIs Using Rust


This post was originally published here

What is REST? What are RESTful Web Services?

What is REST? What are RESTful Web Services?

This tutorial provides an introduction to RESTful web services and goes over what REST is as well as HTTP.

REST stands for REpresentational State Transfer. It is a popular architectural approach to create your API's in today's world.

You Will Learn
  • What is REST?
  • What are the fundamentals of REST APIs?
  • How do you make use of HTTP when building REST API?
  • What is a Resource?
  • How do you identify REST API Resources?
  • What are some of the best practices in designing REST API?
What Is REST?

The acronym REST stands for REpresentational State Transfer. It was term originally coined by Roy Fielding, who was also the inventor of the HTTP protocol. The striking feature of REST services is that they want to make the best use of HTTP. Let's now have a quick overview of HTTP.

A Relook at HTTP

Let's open up the browser and visit a web page first:

And then click on one of the result pages:

Next, we can click on the link on the page we end up in:

And land upon another page:

This is how we typically browse the web.

When we browse the internet, there are a lot of things that happen behind the scenes. The following is a simplified view of what happens between the browser, and the servers running on the visited websites:

The HTTP Protocol

When you enter a URL such as https://www.google.com in the browser, a request is sent to the server on the website identified by the URL. That server then responds with a response. The important thing is the formats of these requests and responses. These formats are defined by a protocol called HTTPHyper Text Transfer Protocol.

When you type in a URL at the browser, it sends out a GET request to the identified server. The server then replies with an HTTP response that contains data in HTMLHyper Text Markup Language. The browser then takes this HTML and displays it on your screen.

Let's say you are filling in a form present on a web page with a list of details. In such a scenario when you click the Submit button, an HTTP POST request gets sent out to the server.

HTTP and RESTful Web Services

HTTP provides the base layer for building web services. Therefore, it is important to understand HTTP. Here are a few key abstractions.

Resource

A resource is a key abstraction that HTTP centers round. A resource is anything you want to expose to the outside world through your application. For instance, if we write a todo management application, instances of resources are:

  • A specific user
  • A specific todo
  • A list of todos

Resource URIs

When you develop RESTful services, you need to focus your thinking on the resources in the application. The way we identify a resource to expose, is to assign a URIUniform Resource Identifier — to it. For example:

  • The URI for the user Ranga is /user/ranga
  • The URI for all the todos belonging to Ranga is /user/Ranga/todos
  • The URI for the first todo that Ranga has is /user/Ranga/todos/1

Resource Representation

REST does not worry about how you represent your resource. It could be XML, HTML, JSON, or something entirely different! The only important thing is you clearly define your resource and perform whatever actions that are supported on it by making use of features already provided by HTTP. Examples are:

  • Create a user: POST /users
  • Delete a user: DELETE /users/1
  • Get all users: GET /users
  • Get a single user: GET /users/1
REST and Resources

A significant point to note is that with REST, you need to think about your application in terms of resources:

  • Identify what resources you want to expose to the outside world
  • Make use of the verbs already specified by HTTP to perform operations on these resources

Here is how a REST service is generally implemented:

  • Data Exchange Format: No restriction is imposed over here. JSON is a highly popular format, although other such as XML can be used as well
  • Transport: Always HTTP. REST is completely built on top of HTTP.
  • Service Definition: There is no standard to specify this, and REST is flexible. This could be a drawback in some scenarios, as it might be necessary for the consuming application to understand the request and response formats. There are widely used ones however, such as WADL (Web Application Definition Language) and Swagger.

REST focuses on resources and how effectively you perform operations on them using HTTP.

The Components of HTTP

HTTP defines the following for a request:

For the response, HTTP defines the:

HTTP Request Methods

The method used in a HTTP request indicates what action you want to perform with that request. Important examples are:

  • GET: Retrieve details of a resource
  • POST : Create a new resource
  • PUT: Update an existing resource
  • DELETE: Delete a resource

HTTP Response Status Code

A status code is always present in a HTTP response. Common examples are:

  • 200: Success
  • 404: Page not found
Summary

In this article, we had a high-level look at REST. We stressed the fact that HTTP is the building block of REST services. HTTP is a protocol that is used to define the structure of browser requests and responses. We saw that HTTP deals mainly with resources that are exposed on web servers. Resources are identified using URIs, and operations on these resources are performed using verbs defined by HTTP.

Finally, we looked at how REST services make the best use of features offered by HTTP to expose resources to the outside world. REST does not put any restrictions on the resource representation formats or on the service definition.