## 2 Architecture
### M2M Gateway Resource Control and Management  
#### 2.2.1 Resource Definition  
After abstraction, the data in the entire system is labeled as different resources, whereas the server can display different resources according to varying data requests from the client end. Moreover, the resources may exist in a variety of formats, e.g., html, xml, and json. Because the system adopts the standard hypertext transfer protocol (HTTP) method, we do not need to worry about changing the name of the interface. In the RESTful M2M gateway system, the data source must be accessed on the M2M gateway from the client end, and the real-time data inspection and the data control for the sensor occur in the sub-station. In this system, there are many sub-stations connected to the M2M gateway, and every sub-station has many sensors. Additionally, for different sub-stations, there are the same sensors as well as different sensors. Consequently, a hierarchical sensor design is implemented in these production bases. The key to the RESTful M2M gateway architecture is the abstraction of the users' demands as a resource. In general, as the abstraction becomes more accurate, the structure of the entire system becomes clearer. The style of REST architecture is to create, read, update, and delete (CRUD) the resource on the server. Therefore, the resource on the gateway is designed according to the REST architecture. When querying the value of a certain sensor, the PLC number connected by the sensor and the sub-station number of the PLC must both be known. They can be found by abstracting the corresponding resource through the monitoring and control of resources, _i.e._, by query and modification. In this situation, the definition of resources includes the sub-station information, the PLC information, and the sensor information, as shown in Table 5.  
In a system based on REST, the resource is identified with a URL, and every URL represents a resource. The whole system consists of resources, and therefore, the key for the design of a systematic structure is whether the URLs are designed reasonably. URL design does not have a unified norm; however, network applications are usually hierarchical. Therefore, the URL design must also reflect the hierarchy. A hierarchical structure is adopted in the resource quest module. For example, /stations is the collection of production bases, /stations/1 is the sub-station with :id equal to 1, /stations/1/plcs is all the PLC information for the No.1 sub-station, and /stations/1/plcs/1 is the information of the No.1 PLC accessing the No.1 sub-station. The specific resource label is shown in Table 6.  
The REST architecture specifies the method to define the application program interface. To facilitate the data transfer between the program on the client end and the server resource, the HTTP application protocol is used to contact the resource, and the GET, PUT, POST, and DELETE methods are used to perform the relevant operations on the resource. A section of the interface for the query operation and the update operation for the resource are shown in Table 7. \begin{table}
\begin{tabular}{c c} \hline \hline
**Resource Name** & **URL Label for Resources** \\ \hline collection of sub-stations; & /stations \\ specific sub-station & /stations/\{stationed\} \\ all PLCs under sub-station & /stations/\{stationed\}/plcs \\ PLC under sub-station & /stations/\{stationed\}/plcs/\{plcid\} \\ sensor under certain PLC & /stations/\{stationed\}/plcs/\{plcid\}/\{sensorid\} \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Definition of resource labels.