Also, as a condition for a resource to be a resource, the resource has at least one URI.

ROA characteristics

• Addressability
• Stateless
• Connectability
• Uniform Interface

Let's look at each one

Addressability

The information provided can be expressed through a URI. All information must have a unique address represented by a URI.

For example, if the basic URI is: http://example.com

If you want to know the information of a specific user http://example.com/users/1

If you want to know information about cats http://example.com/cat

If you want to know mouse information http://example.com/mouse

You can understand the information to be provided just by looking at the URI.

Stateless

Must be a stateless client / server protocol based on HTTP. The exchanged information can be completely interpreted by itself without managing the state of sessions.

This is easy to understand the following analogy

(Stateful example): Customer: Hello Clerk: Welcome. Welcome to XX Burger Customer: I'd like a hamburger set Clerk: What would you like to have on the side menu? Customer: With potatoes Clerk: What would you like to drink? Customer: With ginger ale Clerk: How about making a drink L size for +50 yen? Customer: M is fine Clerk: Are you sure you want to do that? Customer: Yes Clerk: I'm clever

(Stateless example): Customer: Hello Clerk: Welcome. Welcome to XX Burger Customer: I'd like a hamburger set Clerk: What would you like to have on the side menu? Customer: Please give me a hamburger set with potatoes Clerk: What would you like to drink? Customer: Please give me a hamburger set with potatoes and ginger ale Clerk: How about making a drink L size for +50 yen? Customer: Please give me a hamburger set with potatoes and ginger ale (M) Clerk: Are you sure you want to do that? Customer: I'd like a hamburger set with potatoes and ginger ale (M). that's all Clerk: I'm clever

If you think of the clerk as a server, the clerk has been dealing with one customer all the time. During that time, it is not possible to deal with other customers. When the store is crowded (when access increases) Increase the number of clerk (additional WEB server) to respond.

In a normal store, one clerk always accepts the same customer at one cash register, In the case of WEB, since multiple WEB servers receive multiple clients at the same time, If it is a stateless server, a separate clerk will be assigned to each interaction as described above. It becomes possible to respond to the customer's order.

Source What is stateless

Connectivity

Being able to include other information or links to that information inside the information.

Uniform Interface

All information manipulations (get, create, update, delete) are HTTP methods (GET, POST, PUT, DELETE) To use.

GET A method to get the information of the specified URI. This includes getting web pages, images, videos, and feeds.

POST POST has the following three roles.

1. Create a child resource for the parent resource

For example, suppose you have such a blog resource (parent). 　http://example.com/myblog

Then, individual blog entries (child resources), 　http://example.com/myblog/entries/1

Can be provided as.

2. Add data to the resource

Add data to an existing resource. The difference from the previous one is whether the resources have a parent-child relationship. http://example.com/myblog

3. Overlord POST

Execute processing that cannot be handled by other methods. However, this usage deviates from the unified interface in ROA, so it is better not to use it as much as possible.

PUT There are two ways to use PUT.

• Create a new resource
• Update existing resources

Looking at this alone, it may seem that the role is similar to POST.

Creating a child resource for a parent resource = Creating a new resource Add data to resources = Update existing resources

In fact, there seems to be no clear answer. However, the following guidelines exist as design guidelines.

There is no correct answer to this, but the following facts are a design guide. When creating a resource by POST, the client cannot specify the URI of the resource. The decision on the URI rests with the server. Conversely, when creating a resource with PUT, the URI of the resource is determined by the client. (Omitted) In general, the ability of a client to determine a resource's URI means that the programmer making the client is familiar with the server's internal implementation (what characters are allowed in the URI, what is the length limit, etc.). Must be. Therefore, PUT inevitably has a tighter connection with the server. Unless there is a special reason, it is desirable to design the resource to be created by POST and the URI is also decided on the server side. [Source: Technologies that support the Web ── HTTP, URI, HTML, and REST]

I also found such a question when I investigated the difference between POST and PUT. Is PUT processing that only updates in REST API appropriate?

Taking these contents into consideration, POST is used to create a new resource, and PUT is used to update a resource.

DELETE When a client deletes an unnecessary resource, it makes a DELETE request to that URI. Send and delete the resource.

That's all about the unified interface.

Bonus What is CRUD?

Clad (CRUD) is the four main functions required for a system. Arranged terms of "Create", "Read", "Update", and "Delete"

Of the HTTP methods, GET, POST, PUT, DELETE satisfy "CRUD"

Bonus Bonus About Rails resources

In Rails, you can write as follows.

config/routes.rb

Sampleapp::Application.routes.draw do
  resources :users
end

And this code defines the following routing

It's convenient to be able to support RESTful with just this code.