Study of the architecture for a new webbased software system using commercial ERP system

Transcription

1 Study of the architecture for a new webbased software system using commercial ERP system Bram Cooreman under supervision of: Ari Rantala, TAMK Jari Mikkolainen, TAMK Esa Kujansuu, TAMK Wim Catteeuw, KHBO Joan Peuteman, KHBO Jeroen Boydens, KHBO Master s thesis June 2013 IT engineering

2 ACKNOWLEDGEMENT I would like to thank my parents to give me this opportunity to do my thesis and finish my studies here in Tampere, Finland. This was a great experience for me. I also would like to thank Ari Rantala, for helping me when I changed subject and guiding me to the correct persons. I would like to thank my supervisors Jari Mikkolainen and Esa Kujansu, they gave me the thesis subject and helped me during my project. I would like to thank Wim Catteeuw and Joan Peuteman from the KHBO (Katholieke Hogeschool Brugge-Oostende). They gave me the opportunity to do my thesis in Tampere, and Mr Catteeuw for guiding and helping me along with my thesis. I also want to thank the KHBO for the education and the possibility to go on Erasmus. I should not forget to thank Lien Vercruysse and Sina Tee, they helped me with correcting my thesis. Studying in Tampere, was a great experience and I have met a lot of new people, with different culture and interests. I have learned a lot of new things both personally and professionally. Bram Cooreman Tampere 2013

3 ABSTRACT Tampereen ammattikorkeakoulu Tampere University of Applied Sciences Degree Programme in ICT Engineering Bram Cooreman: Study of the architecture for a new web-based software system using commercial ERP system Master s thesis 75 pages June 2013 The thesis covers the study of an architecture for a new web-based system which uses a commercial ERP system. There are business students at the university of TAMK that uses the ERP system. The ERP system makes it possible for them to create and maintain their own company. Every company has the possibility to use a couple of services that are offered by the system, like: banking, automatic ordering system, accounting. The current system is getting old and is not able to withstand more companies and users. A study is necessary to make sure that the new system is compatible with the requirements of the users and the system. The new system needs to support the services of the old system. The university would like to sell or rent the system to other universities of Finland or to different countries as well. When the new system is used in different universities, there will be different types of databases. To make sure that the system will work across the different universities, there needs to be an interface layer between the database and the different services. This interface layer makes it possible to have only one connection to the database. Key words: erp, cloud computing, rest, rest-ful api

4 CONTENTS 1 INTRODUCTION THE CLOUD History Types of cloud computing The Public Cloud The Private Cloud The Hybrid Cloud Different services Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) Conclusion ENTERPRISE RESOURCE PLANNING (ERP) SYSTEM WEB-BASED ARCHITECTURE HyperText Transfer Protocol (HTTP) Request methods HyperText Transfer Protocol Secure (HTTPS) Secure Socket Layer (SSL) Handshake SSL limitations Hypertext Preprocessor (PHP) Representational State Transfer (REST) Constraints REST-ful Application Programming Interface (API) Resources URL format HTTP methods HTTP response codes CURL OAuth Authentication Framework Data representation... 54

5 4.6 MVC framework MATURITY MODEL Richardson Maturity Model Level Level Level Level Other Maturity Model Level 0 Not a REST-ful framework Level 1 Mapping/routing and HTTP/URI encapsulation Level 2 Media Type Support and Client support Level 3 REST elements modelled into language Level 4 Hypermedia as State Engine plus Semantic Support Level 5 CoD and layering support Conclusions and concerns General Conclusion Future work Bibliography... 76

6 ABBREVIATIONS AND TERMS UTF-8 ARPANET API COD ERP XML HATEOAS HTML HTTP HTTPS IaaS JSON PaaS PHP REST RMM SSL SaaS TCP/IP TLS URI URL 8-bit Unicode Transformation Format Advanced Research Projects Agency Network application programming interface Code on Demand Enterprise Resource Planning Extensible Markup Language Hypermedia as the engine of application state HyperText Media Language HyperText Transfer Protocol HyperText Transfer Protocol Secure Infrastructure as a Service JavaScript Object Notation Platform as a Service Hypertext Preprocessor Representation State Transfer Richardson Maturity Model Secure Socket layer Software as a Service Transport Control Protocol/ Internet Protocol Transport Layer Security uniform recourse identifier Uniform Resource Locator

7 LIST OF FIGURES Figure 1 Private, Hybrid and Public clouds (Beaver, 2013)...13 Figure 2 Overview of the different services (Bikeborg, File: Cloud_computing_layers, 2013)...15 Figure 3 Influence of the user and the service provider (Sameer Shelke, Microsoft Windows Azure Secure Development, 2011)...16 Figure 4 SSL handshake (IBM, An overview of the SSL handshake, 2012)...23 Figure 5 PHP (Goodrich, 2012)...25 Figure 6 PHP and HTML code...25 Figure 7 Client Server constraint (Fielding, 2000)...26 Figure 8 Client-Stateless-Server (Fielding, 2000)...27 Figure 9 Client-Cache-Stateless-Server (Fielding, 2000)...28 Figure 10 REST (Fielding, 2000)...30 Figure 11 Web API (Massé, 2012)...31 Figure 12 HTML code with relative URL...34 Figure 13 HTML code with absolute URL...34 Figure 14 GET request...35 Figure 15 Response of the GET method...36 Figure 16 POST request...37 Figure 17 POST server response...38 Figure 18 GET request of one book...38 Figure 19 PUT request...39 Figure 20 DELETE request...40 Figure 21 DELETE responds...40 Figure 22 Curl GET request...43 Figure 23 Curl POST method...44 Figure 24 Curl PUT method(sandoval, 2009)...45 Figure 25 Curl DELETE method (Sandoval, 2009)...45 Figure 26 Generate a server.key...46 Figure 27 Certificate Signing Request...46 Figure 28 Sign the Certificate...46 Figure 29 OAuth2 authentication flow (IdentityManagement, 2012)...48 Figure 30 Authorization Code grant (Gazit, 2012)...50

8 Figure 31 Implicit grant flow (hansamann, 2012)...51 Figure 32 Resource owner password credentials flow (hansamann, OAuth2: The Resource Owner Password Flow, 2012)...52 Figure 33 Client Credentials flow (hansamann, OAuth: the Client Credentials Flow, 2012)...53 Figure 34 XML example (Data, 2013)...54 Figure 35 SimpleXML example...55 Figure 36 JSON example...56 Figure 37 JSON code example...57 Figure 38 MVC architecture...59 Figure 39 Steps to RESTful API (Fowler, 2010)...61 Figure 40 Level 0 example (Fowler, 2010)...62 Figure 41 POST Appointment(Fowler, 2010)...62 Figure 42 Response of Server(Fowler, 2010)...63 Figure 43 Book an appointment(fowler, 2010)...63 Figure 44 Level 1 adding resources (Fowler, 2010)...64 Figure 45 Request to a resource(fowler, 2010)...64 Figure 46 Server response with resources (Fowler, 2010)...65 Figure 47 Client books an appointment with resource (Fowler, 2010)...65 Figure 48 Server Reply in level 1 (Fowler, 2010)...66 Figure 49 Level 2 with HTTP verbs (Fowler, 2010)...66 Figure 50 GET request (Fowler, 2010)...67 Figure response of the server(fowler, 2010)...67 Figure 52 Level 3 with the use of hypermedia controls (Fowler, 2010)...68 Figure 53 GET method in level 3 (Fowler, 2010)...68 Figure 54 HTTP response level 3(Fowler, 2010)...69 Figure 55 POST method level 3 (Fowler, 2010)...70 Figure 56 Server response with Hypermedia controllers(fowler, 2010)...71

9 1 INTRODUCTION 9 This thesis was made for the Tampere University of Applied Sciences (see Figure 3). In the first initial meeting with Esa Kujansuu and Jari Mikkolainen, they told me that the business students use a system called Kykylaakso (see Figure 1). Kykylaakso makes use of an ERP (Enterprise Resource Planning) system. This system makes it possible to simulate and run a company. The system let the students do bank transactions and make orders with other companies. But there are some problems with the system; the database is not properly set up, it doesn t have any relations. The Finnish character set isn t supported, and the system is becoming a bottle neck. Figure 1 Kykylaakso (TAMK, 2008) The university wants to change the system, because the idea is that it can be used later on for other universities in Finland and maybe in the future for universities of other countries. In order to make sure that the new ERP system isn t going to be a bottle neck, a study of the architecture needs to be done. The new system is going to be a web-based architecture like Kykylaakso. Figure 2 Ainopankki (TAMK, 2008) In the current system there are some services that are useful for the new system e.g. Ainopankki (see Figure 2). This service makes it possible to make bank transactions between the different companies. Because the administrators of the new system don t want to rewrite the same service, there has to be a way to make sure that they can reuse that service. So Esa and Jari asked me to make an extra layer between the client and the

10 server (in this case the database), so in case the database changes from e.g. MySQL to Oracle, it doesn t have much problems. 10 Figure 3 Tampere University of Applied Sciences

11 2 THE CLOUD 11 The cloud is a very complex concept. Whereas most people think that the cloud equals the web, there is a lot more to it than meets the eye. There are different definitions concerning cloud computing, with each definition describing a part of the cloud. In the white paper A break in the clouds: towards a cloud definition published by ACM computer communication Reviews, the authors found over 20 different definitions of cloud computing. They assembled some of the main notions into: A large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically reconfigured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs. (Luis M. Vaquero, 2009) The following paragraphs explain the history, the different types of cloud computing, the different services and an end conclusion. 2.1 History In 1969 J.C.R. Licklider was responsible for the development of ARPANET (Advanced Research Projects Agency Network). This was the beginning of the internet. Licklider had a vision, that everyone on the globe was interconnected and could access programs and data at any site, from anywhere. (Weekly, 2009) Since the early seventies the internet began to grow. Moreover, in the early nineties the offered bandwidth of the internet started to increase significantly. One of the first important milestones in cloud computing was the arrival of SalesForce.com in They introduced the concept of delivering enterprise applications via a simple website. Amazon Web Services came in 2002, which provided a suite of cloud-based services including storage, computation and even human intelligence.

12 12 In 2006 Amazon launched the Elastic Compute Cloud (EC2) as a commercial web service that allows small companies and individuals to rent computers to run their own computer applications on. In 2007 SalesForce.com expanded its efforts with Force.com. This is a developer-based platform (PaaS), which allows companies to build and run all of their business applications and websites through the cloud. Google and Microsoft began to enter cloud computing in The Google App Engine brought low-cost computing and storage services, which led to the arrival of Google Apps. This allows people to store documents on the cloud. Microsoft began to follow these developments with Windows Azure. SalesForce.com began to grow with Database.com, and there was a way for the developers to access the services on the cloud with any device or platform and with any programming language. In 2010 Apple introduced the icloud, allowing synchronizing of photos, apps, music and documents across a string of devices. ' (Weekly, 2009; Prakash, Did You Know Cloud Computing Has Been Around Since the '50s?, 2012; sourya, 2011)

13 2.2 Types of cloud computing 13 There are several types of cloud computing; public cloud, private cloud and hybrid cloud. Each of these clouds has their own advantages and disadvantages. The next paragraphs explain the pros, cons, usage and meaning of each cloud computing types, as seen in Figure 4. Figure 4 Private, Hybrid and Public clouds (Beaver, 2013) The Public Cloud The public cloud is a collection of computing resources (applications, storage, services, ) that are dynamically and scalable provisioned over the internet and hosted by hosting providers (Vendo rs). Those resources can be provided via web apps or web services. All recourses are hosted on a shared system, but each resource operates on its own and is securely encrypted. The public cloud can be used by a small start-up company or a big company that uses the cloud every day. A fee is charged by the cloud provider for each user account. This fee depends on either the usage or a certain quota. The main advantage of a public cloud is that the customer cannot see or control the infrastructure of the cloud. Another advantage is that the resource can be accessed from different places. (Reese, 2009; Anthony T. Velte, 2010; Borko Furht, 2010; Rhoton, 2010; Syed A. Ahson, 2010; KUMARI, 2005)

14 2.2.2 The Private Cloud 14 The private cloud is mainly hosted by a company itself, and uses the private network configuration of the company. A private cloud uses virtualization techniques to enhance scalability, resource management and hardware utilization. Companies use a private cloud, because they can manage the infrastructure. The most significant down side of a private cloud are the high operating and bandwidth costs, making it an expensive investment for the company. There are two kinds of private clouds; a cloud owned by the company itself or a cloud provided by the services provider s data centre. A virtual private cloud is a cloud in a cloud, where the company manages the cloud, but the service provider owns the infrastructure. The advantage of a private cloud is that there is no loss of control or security risks with other cloud infrastructure models. (Reese, 2009; Anthony T. Velte, 2010; Borko Furht, 2010; Rhoton, 2010; Syed A. Ahson, 2010; KUMARI, 2005) The Hybrid Cloud Hybrid cloud means a combination of private cloud and public cloud. Hybrid clouds are often used in corporations that need to maintain some of their applications in their internal infrastructure. The companies want to ensure that confidential data and other sensitive information are secure. Moreover, they also need the scalability and cost benefits of the public cloud. Cloud bursting is a common used term in hybrid cloud computing. It describes the process of an organization using their own computer infrastructure for normal use, while the internet applications are deployed on the public cloud to handle the variable loads. Sometimes it is necessary that the cloud can handle a high/peak load request without failing. (Reese, 2009; Anthony T. Velte, 2010; Borko Furht, 2010; Rhoton, 2010; Syed A. Ahson, 2010; KUMARI, 2005; cloudtweaks, 2012)

15 2.3 Different services 15 Cloud computing can be seen as a broad range of different services. Over time cloud services have evolved as a layered model. There are three main layers: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Each service has its own function and purpose. Figure 5 Figure 5shows an overview of the different services that are available in cloud computing. These differences are discussed in the next chapters. Figure 5 Overview of the different services (Bikeborg, File: Cloud_computing_layers, 2013)

16 Figure 6 shows the responsibility of the user and the service provider for each of the different types of services. 16 Responsibility of Security Figure 6 Influence of the user and the service provider (Sameer Shelke, Microsoft Windows Azure Secure Development, 2011) In Figure 6 there are two main aspects management and security. With traditional IT the management is done by the customer. This means that the client is responsible for the security of the system. In IaaS the service provider will take care of the virtualization, servers, storage and networking, the client will manage the data, middleware and applications. Because the application is totally managed by the client the security is then realised by the client. In PaaS, the platform is provided by the service provider, this means that the provider is responsible for the security of the system. The client only takes care of the data and the applications that are on the cloud. In SaaS, the service provider owns the entire stack, this means that they are also responsible for the security of the system. The client will be responsible for the security policies like user access roles and role management. (Llc., 2012)

17 2.3.1 Software as a Service (SaaS) 17 Software as a Service (SaaS) is the service most visible for end-users. The users make a connection to these services through a web browser or other web portals. The service provider provides the necessary services, with less amount of effort for the IT manager. So all deployment, licensing and billing models are invisible for the end-users. Some characteristics of SaaS services are: centralized management and keeping the services up-to-date. A lot of the services are standardized, but it is possible to change their configuration and scalability, depending on the application. There are a lot of examples and providers that supports SaaS e.g. Salesforce.com, Google, Microsoft, Facebook, etc Platform as a Service (PaaS) Platform as a service (PaaS) is known as an environment for software development, storage and hosting different services over the internet. PaaS makes it possible to make and create a web application without the cost and complexity of buying and managing the underling software/hardware. Cloud platforms act as run-time environment, which support a set of programming languages. They offer libraries and additional services such as reusable components that are available for the programming language. There are several webhosting services that support a variety of active server-side components like Microsoft ASP.NET, java scripts, PHP, Python or Ruby on Rails.

18 2.3.3 Infrastructure as a Service (IaaS) 18 Infrastructure is the backbone of cloud computing. IaaS makes it possible to offer a virtual private server with any physical needs. This can be done without any capital investments on the client s side. IaaS can offer servers, storage, network and operating systems as an on demand service. The customer pays only what he uses. Characteristics of IaaS: Resources are distributed as a service Allows for dynamic scaling Variable cost, grows with the necessary equipment Generally includes multiple users on a single piece of hardware (Kepes, Understanding the Cloud Computing Stack, 2011) 2.4 Conclusion The current system now uses a private cloud, this has the advantage that all the information and all the work is done by the administrators. The downside is that when the system is growing the hardware needs to grow as well. So in order to handle the growth of the system, it is useful that the university use a hybrid cloud. Because then they have their private data in their own cloud, but they can still use the advantages of a public cloud like: expansion of the hardware.

19 3 ENTERPRISE RESOURCE PLANNING (ERP) SYSTEM 19 Enterprise Resource Planning (ERP) system is a management software system that allows the organization to manage all the important parts of its business. ERP software integrates all different features of an operation in the company, including development, manufacturing, marketing, financing, accounting, distribution,. In TAMK university they use the ERP system called Pupesoft. Pupesoft is a system that is made with PHP. The students at TAMK use this system to simulate and virtually run their own company. They can make bank transactions and place orders with other companies. Each of these companies can be managed by the supervising teacher. The teacher has the responsibility of the bank, the automatic ordering systems etc.. There are several services that are provided by Pupesoft, one of these services is Ainopankki. Ainopankki makes it possible to do bank transactions, with the bank or with other companies. Because Pupesoft is becoming a bottleneck, and the database is harder to maintain, the administrators of TAMK wants to change the ERP system. The administrators don t want to rewrite the code for the services that are useful. In order to make sure that the services also work on the new system, an API needs to be developed. This API will take care of the integration of the old services in the new system. The following chapters will explain the web-based architectures and the architecture style that is used to make the API.

20 4 WEB-BASED ARCHITECTURE 20 The system in this project is a web-based architecture. The next chapters discuss HTTP, HTTP requests, HTTPS, PHP, PHP framework, REST and RESTful API in more detail. 4.1 HyperText Transfer Protocol (HTTP) HTTP or HyperText Transfer Protocol is an application protocol used for distributed, collaborative, hypermedia information systems. HTTP is used to transfer data across the Internet or World Wide Web. HTTP defines how the messages are formatted, transmitted and what actions the web servers and browsers should take in response to different commands. The HTTP protocol is a stateless protocol, because each command is independent. The currently latest version is HTTP 1.1, this is the most common deployed version; it is defined in RFC The protocol is a request-response protocol, and is typically used in a client-server model. The client sends a request to the server and the server responds to it. If a request fails the server will send a code that represents the reason why it failed. These codes are well-defined Request methods Every HTTP request has multiple methods also sometimes called verbs. Each method describes a desired action to be performed on the identified resource. Depending on the server implementation, the resource will represent dynamically generated data or preexisting data. The URI identifies the resource. (Abeysinghe, RESTful PHP Web services, 2008) The HTTP verbs are used in the Uniform interface of a REST-ful API, see also section Uniform Interface. Each verb has an associated semantic that helps identifying the action which needs to be performed on the resource.

21 TABLE 1 HTTP request methods (Abeysinghe, RESTful PHP Web services, 2008) 21 Verb POST GET PUT DELETE HEAD Description Sends a resource to the server. Updates the resource in the location identified by the URI. Requests a representation of a resource identified by a URI. Only retrieving data nothing else. Sends a resource to the server, to be stored in the location identified by the URI. Deletes a resource identified by a URI Retrieves the metadata of a resource, identical to the GET request but without the response body TABLE 1 shows a couple of the request methods of HTTP. Each of those methods are used in a REST-ful API. The POST method means Creating a child resource in a parent resource e.g. /items. POST gives the possibility to create a new item. The GET method Reads the information from the server through the URI. The PUT method Updates or inserts an existing item where the URL is known e.g. /items/1234. The last method DELETE is used for Deleting elements from a resource. In a REST-ful API the HTTP methods are referred as CRUD. 4.2 HyperText Transfer Protocol Secure (HTTPS) HyperText Transfer Protocol Secure (HTTPS) is a communication protocol which enables secure communication on the internet. HTTPS is not a communication protocol in itself; however, it uses HTTP throughout an SSL/TLS connection. This makes it possible to send data from and to a server in a bidirectional encrypted way. HTTPS uses the TCP port 443, while regular HTTP uses the TCP port 80. To make sure that the server can accept HTTPS commands, it should have a public key certificate to ensure that verification is possible. Some organizations use their own certification, as they become more secure this way. The site is required to have a full HTTPS connection and all pages should be rendered in HTTPS. In the event that the site has any pages in HTTP, this will cause a security

22 leak. (Wikipedia, HTTP Secure, 2013; K.roshan, What is Https and SSL? and how it works? Explained in Simple English, 2011) Secure Socket Layer (SSL) SSL stands for Secure Socket layer and is a protocol used to provide a secure communication over the internet. The protocol makes it sniffing for important information impossible to do. Not only the security of the website is of importance, but also the communication between the webservers needs to be secure. SSL is a protocol developed by Netscape Communications and RSA Data security. When a SSL connection is set up the connection that is created uses a 128 bit or 256 bit key encryption. The SSL protocol consists out of 2 layers, a record protocol and a handshake protocol. These layers are used on top of the transport protocol like TCP/IP. Both of these layers use asymmetric and symmetric cryptographic algorithms. (IBM, Secure sockets layer overview, 2005) Handshake It is very important that messages which are send to and from the client to the server are encrypted. This is realized by using two keys, a public key and a private key. In general the public key is used to encrypt the message and the private key is used to decrypt the message. In order to make sure that the client can have an encrypted connection there needs to be a handshake. Figure 7 SSL handshake shows the handshake between the client and the SSL server.

23 23 Figure 7 SSL handshake (IBM, An overview of the SSL handshake, 2012) First of all the SSL connection is established by the client that goes to a HTTPS website. 1) The client sends a client hello message to the server, which contains a list of cryptographic information of the client. This information can contain the SSL/TLS version, the cipher suites that are supported by the client, and the different client compression methods. The message contains a 28 byte random string. 2) The server receives the client hello message and responds with a server hello message. This message contains the cipher suite that is chosen by the server out of the list that has been send by the client. It also contains the data compression method, session ID and another random number. The server will send his certificate to the client for the authentication of the client. The digital certificate contains the server s public key. If the client needs to use a resource of the server and that step needs client authentication, the server will request for the client certification. 3) The client will check the server s digital certification to see if it can authenticate the server. If the server authentication fails the user will be informed about the problem. 4) The client will generate a random byte string, which will be used for the computation of a secret key that is used for the encryption of the message data.

24 The random byte string is encrypted with the server s public key that has been send with the digital certificate. 5) If the server has send a client certificate request the client will send a random byte string that is encrypted with the client s private key. The client will send this data along with the client s digital certificate, that contains the client s private key, and it is encrypted by the random number generated by the client. 6) The server will check the client s digital certificate to see if it can authenticate the client. If the client cannot be authenticated then the session will be terminated. If the authentication is successful the server will use its own private key to decrypt the message that has been send. 7) The client will send the server a finished message that is encrypted with the master secret key, to indicate that the client handshake is complete. 8) The server will send the client a finished message that is encrypted with the master secret key, to indicate that the client handshake is complete. 9) The SSL handshake is now complete, during the rest of the SSL conversation the messages will be encrypted with the shared key. (Pierobon, 2011) SSL limitations SSL has several main limitations: When the user wants to use a secure website, he has to take in account that there is a possibility that the website is not legit. To prevent this, the SSL server uses a special certificate to confirm that they are not imposters. The way that the ciphers are used for encrypting is an important issue. When the website uses an unsafe cipher like RC4, the possibility that the site can be cracked is much higher than using a save cipher like AES. The SSL connection is strongly dependent of the implementation of the web browser. (Poretsky, 2013)

25 4.3 Hypertext Preprocessor (PHP) 25 PHP is an acronym that stands for Hypertext Preprocessor. It defines a general purpose server script language that makes it possible to build dynamic web pages. PHP is widely integrated with HTML code; therefore, it is possible to use some of the HTML code in a PHP file. The use of PHP makes it possible to build an application through the use of a browser. Figure 8 PHP (Goodrich, 2012) The following example shows how HTML and PHP code are integrated <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" xml:lang="en" lang="en"> <head> <title>php and HTML example</title> </head> <body> <?php echo This is an example on how the integration of PHP code is possible in a HTML page ;?> </body> Figure 9 PHP and HTML code PHP will be used for the realization of the REST API.

26 4.4 Representational State Transfer (REST) 26 REST is an acronym that stands for Representational State Transfer. REST is a software architectural style for distributed hypermedia system as the World Wide Web. REST was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. The next chapters discuss the principles and the interactions of REST. (Fielding R. T., 2000) Constraints A constraint is a rule that indicates one or more software architecture properties. A group of constraints is referred to as a style. REST style is a group of six constraints: client-server, stateless, cache, uniform interface, layered, Code-On-Demand. Each of these constrains will be discussed in the upcoming paragraphs Client-server A client-server is a model where two programs communicate with each other and exchange data. The client and server software can be located on the same computer or in the same network; however, it is also possible that they run on different computers in a separated network. The client makes a request to the server and the server responds to the client request. The server can contain multiple services or server programs. By using a client-server constraint it is possible to separate the user interface from the data storage. Figure 10 shows the client server communication. (Fielding R. T., 2000) Figure 10 Client Server constraint (Fielding, 2000)

27 Stateless A client-server constraint must be stateless when using REST. A stateless communication means that there is no session state allowed on the server side. Each request from client to server must have all the necessary information. When there is a session state, it is kept on the client side. This constraint increases the visibility, reliability, scalability. Visibility improves as a monitoring system does not need to look further than the current message date. Reliability improves since it becomes easier to find and recover from a particular error. Scalability is improved because, there is no need to store the state between the requests; the server can free component resources easily. Figure 11 shows that every client needs to send all information to the server. (Fielding R. T., 2000) Figure 11 Client-Stateless-Server (Fielding, 2000) Yet, there is also the disadvantage of a decrease in performance with an increase in message size. This increases the repetitive data that needs to be send from client to server.

28 Cache Cache acts as an intermediary between client and server. A cache saves the responses of a request, and can be reused as a response to a later request that is equivalent to the one that has been send to the server. The response needs to be labelled as cacheable or noncacheable. As long as the cache hasn t been expired the response is still up-to-date to the one on the server. This has the advantage of eliminating some interactions and improving user performance. The downside of cache is that the data within the cache can be outdated, which causes wrong information to be send to the client..(fielding R. T., 2000) Figure 12 shows how the client uses the cache to communicate with the server. Figure 12 Client-Cache-Stateless-Server (Fielding, 2000) Uniform Interface A uniform interface is an interface for a component that needs to be as generic as possible. The use of a uniform interface simplifies the overall system architecture and improves the visibility of interactions. The services provided by the implementations are being decoupled, this encourages independent evolution. Still, a uniform interface has the downside of degrading the application efficiency. This happens, as the transferred information is in a standard format, and not suited for the needs of the application. REST interface is suit up for large-grain hypermedia data transfer, optimized for the common case of the web; however, the interface is not optimal for other forms of architectural interaction. A uniform interface is realized by using multiple architecture constraints in order to guide the behaviour of the components. There are four interface constraints that define REST: identification of resources, manipulation of resources through representation,

29 self-descriptive messages and hypermedia as the engine of application state. (Fielding R. T., 2000; Sandoval, 2009) Identification of resources In a web-based system the resources are identified in requests. This may be addressed by a unique identifier, e.g. URI (Uniform Recourse Identifier). The URI is used in REST-ful systems. The resources are conceptually separated from the representations send back to the client. For example XML, JSON or HTML are used to represent data from the database Manipulation of resources through representation A client manipulates the resources through representations. The client holds a representation of a resource, which includes metadata, and he has thus enough information to modify or delete the resource on the server, without changing the resources directly. The client can only send and receive representations from the server. Moreover, it is possible that the exact same resource is represented to other clients in different ways. The main idea is that the representation is a way to communicate with the resource, but it is a copy of the resource. This allows the recourse to be represented in different ways and formats without changing the identifier. (Fielding R. T., 2000) Self-descriptive messages Self-descriptive messages require that every message from client to server must contain all the necessary metadata to describe the meaning of the message. Metadata includes: resource state, the representation format, size and the message itself. HTTP messages provide headers to organize the various types of metadata into well-defined fields. This means that the methods used to invoke the messages must be agreed on and standardized between the client and the server, otherwise the transaction will be rejected.

30 Hypermedia as the engine of application state 30 Hypermedia as the engine of application state or HATEOAS, is a constraint where an application process moves to the next step through hypermedia. The main idea is that a client interacts with a network application entirely through hypermedia which is dynamically provided by the application server. The REST client is not required to know how to interact with any application or server beyond the generic idea of hypermedia Layered system A layered system is organized hierarchically. Each layer provides a service to the layer above it and uses a service from the layer below it. The layers can then talk with other layers which improves the extensibility by using a mechanism to isolate the complexity. The client server model is an example of layer architecture. The layered system allows architecture to be composed of hierarchical layers by restricting the component behaviour which limits the interaction with the immediate layers. By using a layered system (see Figure 13) the knowledge of the system is restricted to a single layer. This causes a limitation on the complexity of the system and encourages an independency. The layers encapsulate there information onto the message, this protects the new services from older services. The components are being simplified by moving the infrequently used functionality to a shared intermediary. The use of intermediaries can improve the system scalability and enables the load balancing of the different services available over the network and processes. Figure 13 REST (Fielding, 2000)

31 31 One disadvantage of a layered system is that every layer adds overhead to the message and this causes latency. The latency can be solved by using shared caches. (Fielding R. T., 2000) Code-on-Demand Code-on-Demand is an optional constraint. The client has access to a couple of resources, but the client does not know the internal working on how to process them. That is why the client sends a request to the server for the code that represents the know-how. Once received, the code can be executed locally. This makes it possible to add code or functions to an existing application, through scripts or plug-ins. Code-on-Demand has the advantage of extensibility and configurability, since the code on client side can be extended after the application has been deployed. The code that has been send to the client can interact with the user locally rather than through remote interactions. Furthermore, the scalability of the server is improved, because the workload is now done by the client. On the other hand, there is a reduced visibility caused by the code itself. 4.5 REST-ful Application Programming Interface (API) The web is continuously growing, and more and more web services are available via the internet. Because developers do not want to reinvent the wheel, they would like to use some of the available web services. This can be done with a web application programming interface (API). A web API is used as a communication layer between the client and the web service, see Figure 14 Web API. A web API commonly uses a REST architecture style, and is then referred to as REST API. The term REST-ful comes from the web services that are using a REST API. (Allamaraju, 2010; Massé, 2012; Abeysinghe, RESTful PHP Web services, 2008) Figure 14 Web API (Massé, 2012)

32 32 A REST API exists out of multiple resources, each of these resources are linked with each other. The client communicates with the API, so in this way the web service is hidden. In case the web service changes, the API can still work with some minor adjustments. This makes an API very powerful, as the client does not have a straight connection to the database. The next paragraphs discuss in more detail the resources, URL format, HTTP methods that are used and the way that the API is communicating with the server through XML/JSON objects Resources The REST API is a way to communicate with the web service and also makes the operations on the information in the web service. The information in the web service is called resource. When considering a REST-ful API the use of resources is a fundamental issue in the design process. The API communicates with the resources through hyperlinks. The hyperlinks show the representation of how the resources are related with each other. A resource is an object that contains data, type, relationships to other resources and some set of methods that can operate on that object. The only methods that can be used on resources are the CRUD methods, see section Each resource has its own resource identifier, URI (uniform resource identifier). A resource can also be used to check the last modified time, this can be passed in the metadata. Resource data can be represented in either XML format or JSON format. Each of these representations has their own advantages and disadvantages, which will be discussed in section A group of resources is called a collection. Each collection can only exist out of one type of resource, which makes the collection is homogenous. (Abeysinghe, RESTful PHP Web services, 2008)

33 4.5.2 URL format 33 A REST API communicates with the web service through hyperlinks. The hyperlinks are called URLs, uniform resource locator. URLs are used to communicate between client and API. The syntax of an URL is: scheme://domain:port/path?query_string#fragment_id Scheme: contains the namespace of the URL. For example this can be the HTTP(S) of a web browser. Domain: this could be the IP address of domain. Commonly this is the name of the domain, e.g. google.com. This translation is caused by the a domain name system (DNS). Port: a port number is optional; by default it is 80 for HTTP and 443 for HTTPS. Path: defines where the resource is located. Query string: the data that needs to be send to the server, for example when the user posts something. Fragment id: this defines the location in the resource or in the document (Wikipedia, Uniform resource locator, 2013) Each resource and collection is represented by a URL. The URL is unique for every resource and collection. The following table shows how the URL mapping happens in a REST API. TABLE 2 URL mapping in REST-ful API (Massé, 2012) URL Description API entry point Top level collection, also called directory of the URL ID selected in the collection, or document

34 There are two ways in the API to represent a URL; relative and absolute. A relative URL does not fully include the file location, as shown in the HTML code in Figure <a href= login.php name= login>login page</a> Figure 15 HTML code with relative URL In an absolute URL the entire path of the file is located. An absolute URL path can be seen in the following HTML code, see Figure 16: <a href= name= login>login page</a> Figure 16 HTML code with absolute URL HTTP methods As discussed in section several HTTP methods are being used by REST. The main methods are called CRUD; create, read, update and delete. Each of these methods is explained in the following examples. Table 3 HTTP methods with REST (Abeysinghe, RESTful PHP Web services, 2008) HTTP Method URI Description GET /book List all the books POST /book Create book(s) GET /book/1 Retrieve book PUT /book/1 Update book DELETE /book/1 Remove book The next sections discuss client requests and server responses of CRUD methods.

35 GET 35 GET /REST/book.php HTTP/1.1 Host: localhost:8080 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-nl,nl;q=0.8,en-us;q=0.6,en;q=0.4 Cookie: tb_geo=fi%3bnull%3bnull Figure 17 GET request Figure 17 shows the GET request that has been send to the server. The client has entered the server sees how the client asks for that information. The most important things in the header field are: GET /REST/book.php HTTP/1.1: there is a get request for the file/document located in REST folder. The protocol that has been used is HTTP 1.1. Host: localhost:8080: the host or domain name is localhost on port Port 8080 is used, since an application registers the traffic on that port. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8: the accept header indicates which content types are acceptable for the response of the server. (Fielding, 1999) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/537.36: this is the useragent string, the browser that is making the request. Cookie: tb_geo=fi%3bnull%3bnull: an http-cookie that previously has been send.

36 The server receives the request and replies with: 36 HTTP/ OK Date: Fri, 24 May :03:20 GMT Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7 X-Powered-By: PHP/5.4.7 Content-Length: 183 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html <books> <book> <id>1</id> <name>book1</name> <author>auth1</author> <isbn>isbn0001</isbn> </book> <book> <id>2</id> <name>book2</name> <author>auth2</author> <isbn>isbn0002</isbn> </book> </books> Figure 18 Response of the GET method Figure 18 shows the response of the server to the GET request. HTTP/ OK: This response indicates that the server can process the request of the client and sends a 200 OK. Date: Fri, 24 May :03:20 GMT: this indicates when the server sent the message to the client. Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7: this represents the server settings and the software that is installed on the server. Content-Length: 183: this indicates the length of the message body that the server sends to the client

37 Content-Type: text/html: this specifies the media type of the entire message body that is send to the client. The actual message POST POST /REST/book.php HTTP/1.1 Host: localhost:8080 Connection: keep-alive Content-Length: 166 Cache-Control: no-cache User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Content-Type: application/xml Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-nl,nl;q=0.8,en-us;q=0.6,en;q=0.4 Cookie: tb_geo=fi%3bnull%3bnull <books> <book><name>book3</name><author>auth3</author><isbn>isbn0003</isbn ></book> <book><name>book4</name><author>auth4</author><isbn>isbn0004</isbn ></book> </books> Figure 19 POST request Figure 19 shows the POST request of the client. Only the differences with the GET request are discussed. POST /REST/book.php HTTP/1.1: The client sends a POST request to the server with the HTTP 1.1 protocol. Content-Type: application/xml: The information that has been send with the POST request is in a XML format The POST message

38 38 The server receives the messages and sends a HTTP 200 OK back. Figure 20 shows the response of the server. It s almost the same as the GET response, the only difference is that the Content-Length : 0. HTTP/ OK Date: Fri, 24 May :20:33 GMT Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7 X-Powered-By: PHP/5.4.7 Content-Length: 0 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html Figure 20 POST server response GET one resource GET /REST/book.php/1 HTTP/1.1 Host: localhost:8080 Connection: keep-alive Cache-Control: no-cache User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-nl,nl;q=0.8,en-us;q=0.6,en;q=0.4 Cookie: tb_geo=fi%3bnull%3bnull Figure 21 GET request of one book Figure 21 shows the request of one book. This is realized by going to the URL the number is the ID of the book that user is requesting. The server then responds with the corresponding book. The answer is the same as the first GET response; however, with the message body being just one book not the entire list.

39 PUT 39 PUT /REST/book.php/1 HTTP/1.1 Host: localhost:8080 Connection: keep-alive Content-Length: 100 Accept: application/xml Cache-Control: no-cache User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Content-Type: application/xml Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-nl,nl;q=0.8,en-us;q=0.6,en;q=0.4 Cookie: tb_geo=fi%3bnull%3bnull; <books> <book> <id>1</id> <name>newbook</name> <author>auth1</author> <isbn>isbn0001</isbn> </book> </book> Figure 22 PUT request Figure 22 shows how the client makes a PUT request. The user puts the new values in the message body. The only difference with a POST method is that the method now is PUT instead of POST. The server responds in the same way as the POST responds.