Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is RESTful". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is RESTful".

REST

REST is not a word, but an acronym for Representational State Transfer.

Literally, it means declarative state transfer.

I've been blinded by this name for more than a year, so I can't say something I can understand.

I turned it over from the paper that put forward REST. I didn't say it clearly, but what I mean is that it actually has a subject Resource.

So it is the declarative state transfer of resources.

It's a little more understandable.

No matter what the state shift is, we will feel something at first.

After knowing REST, RESTful is not difficult to explain. Adding ful is a metamorphic adjective, such as wonderful girl. At this point, I explained the name a little bit, but the doubt is still all right. Let's deal with it slowly.

The core of REST

The core is the resource, which uses URL to locate the resource and HTTP verb to describe the operation to be done.

HTTP provides many verbs: GET, PUT, POST, DELETE.

These verbs have meaning.

For example, GET is to obtain resources, is a query request.

PUT refers to the modification of resources and is idempotent.

POST is also a modification (adding is also a modification), which refers to a non-idempotent operation.

So according to these specifications, we can all know some of the actions of this interaction, so the correct use posture of RESTful style is as follows:

For example, get a user.

Wrong posture: GET / getUserById?userId=1.

Correct posture: GET / users/1.

For example, add user.

Wrong pose: POST / addUser (omitting body).

Correct posture: POST / users (omit body).

You can see that the verb of HTTP can actually refer to what you want to do with a resource, so you don't need to do anything on URL, just think of what URL indicates as a resource.

Note that you should use HTTP verbs, such as PUT for a request to get resources, which can also be used, but this is not appropriate.

In fact, a deeper understanding is that HTTP is a protocol.

In fact, an agreement is an agreed thing, and the agreement stipulates that GET is to obtain resources, so you have to repeat it on URL or all requests use GET action regardless of addition, deletion or modification, which means that this agreement is not fully followed.

It can be said that HTTP is only regarded as a transmission pipeline, not an agreed protocol.

This is actually a deeper understanding of HTTP, and I think that's why RESTful was launched.

Of course, the ideal is very plump, the reality is very bony, there are still a lot of people on getUserById.

But personally, I don't think it's a big problem, as long as the company is unified.

HATEOAS

The abbreviation for Hypermedia as the Engine of Application State translates to hypermedia as an application status engine.

This is also the design proposed by REST.

Don't you understand? It's actually very simple.

I will not make up the example myself, but copy the example in stackoverflow's answer.

For example, if you ask for a list of users:

GET / users Accept: application/json+userdb

The return at this time should be:

`200 OK

Content-Type: application/json+userdb

{

"users": [

{

"id": 1

"name": "Emil"

"country:" Sweden "

"links": [

{

"href": "/ user/1"

"rel": "self"

"method": "GET"

}

{

"href": "/ user/1"

"rel": "edit"

"method": "PUT"

}

{

"href": "/ user/1"

"rel": "delete"

"method": "DELETE"

}

]

}

{

"id": 2

.... Omit.

}

]

"links": [

{

"href": "/ user"

"rel": "create"

"method": "POST"

}

]

}

`

The point is this links, and the result will return what you can do with the resource.

For example, if userId is 1, you call PUT / user/1 to modify the user, and DELETE / user/1 to delete the user.

The outermost links tells you that you can create another user with POST / user.

There is also a hidden message. You can see that the outer links does not return DELETE information, indicating that the client cannot delete the user at this time!

So RESTful API needs to return what it can do with the resource at this time so that the client knows what it can do.

It doesn't need to care exactly what to do, anyway, it will be told in the return that DELETE is like this, and POST is like this.

You can't do what you don't tell it.

Then at this time to understand the declarative state transfer of resources, is it a feeling?

If the last part mentioned using the verb of HTTP to refer to action, URL only means that the reality of the resource is bony.

Then the reality of HATEOAS is the ashes.

Very few companies would do that.

Personally, this thing is useless.

Its starting point is to let the client know the entry of the operation on the resource from the response, and know which actions can be performed through the response.

Thank you for your reading, the above is the content of "what is RESTful", after the study of this article, I believe you have a deeper understanding of what is RESTful, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.