Fix section "RESTful desgin in Beego" in 13.3.md

en/13.3.md

@@ -6,9 +6,9 @@ Most traditional MVC frameworks are based on suffix action mapping. Nowadays, th
 
 The MVC design pattern is currently the most used framework model for web applications. By keeping Models, Views and Controllers separated, we can keep our web applications modular, maintainable, testable and extensible. A model encapsulates data and any of the business logic that governs that data, such as accessibility rules, persistence, validation, etc. Views serve as the data's representation and in the case of web applications, they usually live as templates which are then rendered into HTML and served. Controllers serve as the "glue" logic between Models and Views and typically have methods for handling different URLs. As described in the previous section, when a URL request is forwarded to a controller by the router, the controller delegates commands to the Model to perform some action, then notifies the View of any changes. In certain cases, there is no need for models to perform any kind of logical or data processing, or for any views to be rendered. For instance, in the case of an HTTP 302 redirect, no view needs to be rendered and no processing needs to be performed by the Model, however the Controller's job is still essential. 
 
-## Beego the REST design
+## RESTful design in Beego 
 
-Previous section describes the routing function to achieve a registered struct, and the struct implements REST approach, so we need to design a controller for logic processing base class, where the main design of the two types, a struct, an interface
+The previous section describes registering route handlers with RESTful structs. Now, we need to design the base class for a logic controller that will be composed of two parts: a struct and interface type.    
 
 	type Controller struct {
 		Ct        *Context
@@ -34,7 +34,7 @@ Previous section describes the routing function to achieve a registered struct,
 		Render() error               //method executed after the corresponding method to render the page
 	}
 
-Then add function described earlier, when a route is defined ControllerInterface type, so long as we can implement this interface, so our base class Controller to achieve the following methods:
+Then add the route handling function described earlier in this chapter. When a route is defined to be a `ControllerInterface` type, so long as we can implement this interface, we can have access to the following methods of our base class controller.
 
     func (c *Controller) Init(ct *Context, cn string) {
 		c.Data = make(map[interface{}]interface{})
@@ -115,14 +115,13 @@ Then add function described earlier, when a route is defined ControllerInterface
 		c.Ct.Redirect(code, url)
 	}	
 
+Above, the controller base class already implements the functions defined in the interface. Through our routing rules, the request will be routed to the appropriate controller which will in turn execute the following methods: 
 
-At the controller base class already implements the interface defined functions performed by routing the appropriate controller according url principles will be followed by implementation of the following:
-
-Init() initializes
-Prepare() before the execution of the initialization, each subclass can inherit to implement the function
-method() depending on the method to perform different functions: GET, POST, PUT, HEAD, etc. sub-classes to implement these functions, if not achieved, then the default is 403
-Render() optional, according to a global variable to determine whether to execute AutoRender
-Finish() after the implementation of the action, each subclass inherits the function can be achieved
+    Init() initialization routine 
+    Prepare() pre-initialization routine; each inheritting subclass may implement this function
+    method() depending on the request method, perform different functions: GET, POST, PUT, HEAD, etc. Subclasses should implement these functions; if not implemented, then the default is 403
+    Render() optional method. Determine whether or not to execute according to the global variable "AutoRender"  
+    Finish() is executed after the action been completed. Each inheritting subclass may implement this function 
 
 ## Application guide