|
1 | 1 | # 8.3 REST
|
2 | 2 |
|
3 |
| -RESTful is the most popular software architecture on the internet today, due to its clear, strict standard, easy to understand and expand, more and more websites are based on it. In this section, we are going to know what it really is and how to use this architecture in Go. |
| 3 | +REST is the most popular software architecture on the internet today because it is founded on well defined, strict standards and it's easy to understand and expand. mOre and more websites are basing their designs on to top of it. In this section, we are going to have a close look at implementing the REST architecture in Go and (hopefully) learn how to leverage it to our benefit. |
4 | 4 |
|
5 | 5 | ## What is REST?
|
6 | 6 |
|
7 |
| -The first declaration of the concept of REST(REpresentational State Transfer) was in 2000 in Roy Thomas Fielding's doctoral dissertation, who is the co-founder of HTTP. It's a architecture constraints and principles, anything implemented this architecture we call them RESTful. |
| 7 | +The first declaration of the concept of REST (REpresentational State Transfer) was in the year 2000 in Roy Thomas Fielding's doctoral dissertation, who is also just happens to be the co-founder of the HTTP protocol. It specifies the architecture's constraints and principles and anything implemented with architecture can be called a RESTful system. |
8 | 8 |
|
9 |
| -Before we understand what is REST, we need to cover following concepts: |
| 9 | +Before we understand what REST is, we need to cover the following concepts: |
10 | 10 |
|
11 | 11 | - Resources
|
12 | 12 |
|
13 |
| - REST is the Presentation Layer State Transfer, where presentation layer is actually resource presentation layer. |
| 13 | + REST is the Presentation Layer State Transfer, where the presentation layer is actually the resource presentation layer. |
14 | 14 |
|
15 |
| - So what are resources? A picture, a document or a video, etc. These can all be resources and located by URI. |
| 15 | + So what are resources? Pictures, documents or videos, etc., are all examples of resources and can be located by URI. |
16 | 16 |
|
17 | 17 | - Representation
|
18 | 18 |
|
19 |
| - Resources are specific entity information, it can be showed with variety of ways in presentation layer. For instances, a TXT document can be represented as HTML, JSON, XML, etc; a image can be represented as jpg, png, etc. |
| 19 | + Resources are specific information entities that can be shown in a variety of ways within the presentation layer. For instance, a TXT document can be represented as HTML, JSON, XML, etc; an image can be represented as jpg, png, etc. |
20 | 20 |
|
21 |
| - Use URI to identify a resource, but how to determine its specific manifestations of it? You should use Accept and Content-Type in HTTP request header, these two fields are the description of presentation layer. |
| 21 | + URIs are used to identify resources, but how do we determine its specific manifestations? You should the Accept and Content-Type in an HTTP request header; these two fields describe the presentation layer. |
22 | 22 |
|
23 | 23 | - State Transfer
|
24 | 24 |
|
25 |
| - An interactive process happens between client and server when you visit a website. In this process, certain data related to the state change should be saved; however, HTTP is stateless, so we need to save these data on the server side. Therefore, if the client wants to change the data and inform the server-side state changes, it has to use some way to tell server. |
| 25 | + An interactive process is initiated between client and server each time you visit any page of a website. During this process, certain data related to the current page state need to be saved. However, you'll recall that HTTP is a stateless protocol! It's obvious that we need to save this client state on our server side. It follows that if a client modifies some data and wants to persist the changes, there must be a way to inform the server side about the new state. |
26 | 26 |
|
27 |
| - Most of time, the client informs server through HTTP. Specifically, it has four operations: GET, POST, PUT, DELETE, where GET to obtain resources, POST to create or update resources, PUT to update resources and DELETE to delete resources. |
| 27 | + Most of the time, clients inform servers of state changes using HTTP. They have four operations with which to do this: |
28 | 28 |
|
29 |
| -In conclusion of above explanations: |
| 29 | + -GET is used to obtain resources |
| 30 | + -POSTs is used to create or update resources |
| 31 | + -PUT updates resources |
| 32 | + -DELETE deletes resources |
30 | 33 |
|
31 |
| -- (1)Every URI reresented a kind of resource. |
32 |
| -- (2)A representation layer for transferring resources between clients and servers. |
33 |
| -- (3)Clients use four operation of HTTP to operation resources to implement "Presentation Layer State Transfer". |
| 34 | +To summarize the above: |
34 | 35 |
|
35 |
| -The most important principle of web applications that implement REST is that interactive between clients and servers are stateless, and every request should include all needed information. If the server restart at anytime, clients should not get notification. In addition, requests can be responded by any server of same service, which is good for cloud computing. What's more, because it's stateless, clients can cache data for performance improvement. |
| 36 | +- (1)Every URI reresents a resource. |
| 37 | +- (2)There is a representation layer for transferring resources between clients and servers. |
| 38 | +- (3)Clients use four HTTP methods to implement "Presentation Layer State Transfer", allowing them to operate on remote resources. |
36 | 39 |
|
37 |
| -Another important principle of REST is system delamination, which means components have no way to have direct interaction with components in other layers. This can limit system complexity and improve the independence of the underlying. |
| 40 | +The most important principle of web applications that implement REST is that the interaction between clients and servers are stateless; every request should encapsulate all of the required information. Servers should be able to restart at anytime without the clients being notified. In addition, requests can be responded by any server of the same service, which is ideal for cloud computing. Lastly, because it's stateless, clients can cache data for improving performance. |
| 41 | + |
| 42 | +Another important principle of REST is system delamination, which means that components in one layer have no way of interacting directly with components in other layers. This can limit system complexity and encourage independence in the underlying components. |
38 | 43 |
|
39 | 44 | 
|
40 | 45 |
|
41 | 46 | Figure 8.5 REST architecture
|
42 | 47 |
|
43 |
| -When the constraint condition of REST apply to the whole application, it can be extended to have huge amounts of clients. It also reduced interactive delay between clients and servers, simplified system architecture, improved visibility of sub-systems interaction. |
| 48 | +When RESTful constraints are judiciously abided by, web applications can be scaled to accommodate massive numbers of clients. Using the REST architecture can also help reduce delays between clients and servers, simplify system architecture and improve the visibility of sub-system end points. |
44 | 49 |
|
45 | 50 | 
|
46 | 51 |
|
47 | 52 | Figure 8.6 REST's expansibility.
|
48 | 53 |
|
49 | 54 | ## RESTful implementation
|
50 | 55 |
|
51 |
| -Go doesn't have direct support for REST, but because RESTful is HTTP-based, so we can use package `net/http` to achieve them own. Of course we have to do some modification in order to implement REST. REST uses different methods to handle corresponding resources, many existed applications are claiming to be RESTful, in fact, they didn't not really realize REST. I'm going to put these applications into several levels depends on the implementation of methods. |
| 56 | +Go doesn't have direct support for REST, but since RESTful web applications are all HTTP-based, we can use the `net/http` package to implement it on our own. Of course, we will first need to make some modifications before we are able to fully implement REST. |
| 57 | + |
| 58 | +REST uses different methods to handle resources, depending on the interaction that's required with that resource. Many existing applications claim to be RESTful but they do not actually implement REST. I'm going to categorize these applications into several levels depends on which HTTP methods they implement. |
52 | 59 |
|
53 | 60 | 
|
54 | 61 |
|
55 | 62 | Figure 8.7 REST's level.
|
56 | 63 |
|
57 |
| -Above picture shows three levels that are implemented in current REST, we may not follow all the rules of REST when we develop our applications because sometimes its rules are not fit for all possible situations. RESTful uses every single HTTP method including `DELETE` and `PUT`, but in many cases, HTTP clients can only send `GET` and `POST` requests. |
| 64 | +The picture above shows three levels that are currently implemented in REST. You may not choose to follow all the rules and constraints of REST when developping your own applications because sometimes its rules are not a good fit for all situations. RESTful web applications use every single HTTP method including `DELETE` and `PUT`, but in many cases, HTTP clients can only send `GET` and `POST` requests. |
58 | 65 |
|
59 |
| -- HTML standard allows clients send `GET` and `POST` requests through links and forms, it's not possible to send `PUT` or `DELETE` requests without AJAX support. |
60 |
| -- Some firewalls intercept `PUT` and `DELETE` requests, clients have to use POST in order to implement them. RESTful services in charge of finding original HTTP methods and restore them. |
| 66 | +- HTML standard allows clients send `GET` and `POST` requests through links and forms. It's not possible to send `PUT` or `DELETE` requests without AJAX support. |
| 67 | +- Some firewalls intercept `PUT` and `DELETE` requests and clients have to use POST in order to implement them. Fully RESTful services are in charge of finding the original HTTP methods and restoring them. |
61 | 68 |
|
62 |
| -We now can simulate `PUT` and `DELETE` by adding hidden field `_method` in POST requests, but you have to convert in your servers before processing them. My applications are using this way to implement REST interfaces; sure you can easily implement standard RESTful in Go as following example: |
| 69 | +We can simulate `PUT` and `DELETE` requests by adding a hidden `_method` field in our POST requests, however these requests must be converted on the server side before they are processed. My personal applications use this workflow to implement REST interfaces. Standard RESTful interfaces are easily implemented in Go, as the following example demonstrates: |
63 | 70 |
|
64 | 71 | package main
|
65 | 72 |
|
@@ -103,11 +110,11 @@ We now can simulate `PUT` and `DELETE` by adding hidden field `_method` in POST
|
103 | 110 | http.ListenAndServe(":8088", nil)
|
104 | 111 | }
|
105 | 112 |
|
106 |
| -This sample shows you have to write a REST application. Our resources are users, and we use different functions for different methods. Here we imported a third-party package `github.com/drone/routes`, we talked about how to implement customized router in previous chapters; this package implemented very convenient router mapping rules, and it's good for implementing REST architecture. As you can see, REST requires you have different logic process for different methods of same resources. |
| 113 | +This sample code shows you how to write a very basic REST application. Our resources are users, and we use different functions for different methods. Here, we imported a third-party package called `github.com/drone/routes`. We've already covered how to implement a custom router in previous chapters -the `drone/routes` package implements some very convenient router mapping rules that make it very convenient for implementing RESTful architecture. As you can see, REST requires you to implement different logic for different HTTP methods of the same resource. |
107 | 114 |
|
108 | 115 | ## Summary
|
109 | 116 |
|
110 |
| -REST is a kind of architecture style, it learnt successful experiences from WWW: stateless, centered on resources, fully used HTTP and URI protocols, provides unified interfaces. These superiority let REST become more popular web services standard. In a sense, by emphasizing the URI and the early Internet standards such as HTTP, REST is a large application Web-server era before the return. Currently Go For REST support is still very simple, by implementing a custom routing rules, we can think that a different method to achieve different handle, thus achieving a REST architecture. |
| 117 | +REST is a style of web architecture, building on past successful experiences with WWW: statelessness, resource-centric, full use of HTTP and URI protocols and the provision of unified interfaces. These superior design considerations has allowed REST to become the most popular web services standard. In a sense, by emphasizing the URI and leveraging early Internet standards such as HTTP, REST has paved the way for large and scalable web applications. Currently, the support that Go has For REST is still very basic. However, by implementing custom routing rules and different request handlers for each type of HTTP request, we can achieve RESTful architecture in our Go webapps. |
111 | 118 |
|
112 | 119 | ## Links
|
113 | 120 |
|
|
0 commit comments