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.

40 DELETE DELETE /REST/book.php/1 HTTP/1.1 Host: localhost:8080 Connection: keep-alive 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 Figure 23 DELETE request Figure 23 shows the DELETE request to the server, the user wants to delete the first record in the list. The server responds with a HTTP 200 OK as showed in Figure 24. HTTP/ OK Date: Sat, 25 May :31:28 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 24 DELETE responds Each of these methods now has a positive response (200 OK). Yet, there are also other response status codes, which are discusses in the next paragraph.

41 4.5.4 HTTP response codes 41 Every response that comes from the server has a response code included. There are a lot of response codes, so only the ones that are important for curl and the REST API will be discussed xx Success The 2xx class discusses the responses where the client request was successfully received, accepted and understood. (Fielding e. a., 1999) 200 OK: The request is received successfully; the response is depending on the request. 201 Created: The request is completed, and the answer put in a new request. 202 Accepted: The server accepted the request but has not completed it yet. 204 No Content: The server completed the request; the answer does not contain any message body xx Client Error The 4xx class, this class indicates that there has been an error at the client or user side. 400 Bad Request: The request that sent to the server could not be processed because of a syntax error. 401 Unauthorized: The request needs authentication, since the user cannot be authenticated, it will return an unauthorized error. 403 Forbidden: The requested page or document is not available for the user because the user is not authorized to access it. 404 Not Found: The requested page or document is not found on the server xx Server Error The 5xx class appears in case of a server error; the server is aware of an error and sends it back to the client. 500 Internal Server Error: When a fault occurs on the server side, generally the 500 Internal Server Error will be thrown. If this error message appears, the client tries to send the same request again hoping for another response.

42 4.5.5 CURL 42 Curl is a software program that provides a library and command-line. The curl program makes it possible to send and receive data from the server. Moreover, the tool can support different protocols. Curl is used in this project is by using the libcurl. The next paragraphs will explain the workings of libcurl. (Stenberg, 2013) Explanation of libcurl resource curl_init([string URL]): This initializes the curl session, returns a valid session or false in case of a fault. The URL string contains the URL where the curl needs to get its information. The URL can also be set manually. boolcurl_setopt(intcurlid, int option, mixed value): curlid is the session of the curl; option contains the option value that needs to be set, value is the value of the option. Several options are being used: o CURLOPT_URL: This contains the resource URL. It will be set and overridden if it was already set in the curl_init(). o CURLOPT_RETURNTRANSFER: This option acts as a toggle; when the value is true then the output is fetched by curl_exec() otherwise it is handled by a file handle (default STDOUT). o CURLOPT_POST: If this value is set to true then the curl will perform a HTTP POST request. o CURLOPT_POSTFIELDS: This option contains an array of the values send with a POST method and is necessary if the CURLOPT_POST is set. o CURLOPT_PUT: To put a file to the server. o CURLOPT_INFILE: the file that needs to be read for the upload. o CURLOPT_INFILESIZE: The expected file size in bytes. o CURLOPT_CUSTOMREQUEST: a custom request method instead of GET or HEAD, useful for the DELETE request. o CURLOPT_SSL_VERIFYPEER: This option acts as a toggle. If the value is set to false then the SSL certificate will not be verified. If the value is set to true then the SSL certificate will be checked, the certificate will be passed with the option cainfo. Default value is true. o CURLOPT_SSL_VERIFYHOST: This option can have 3 values: 0 Do not check the common name (CN) attribute, 1: Check that the common name attribute exists in the SSL certificate, 2: Check that the common name exists and that it matches the host name of the server. (Chng, 2009) o CURLOPT_CAINFO: This option contains the path to the server certification. (Torben Wilson, 2001) Mixed curl_exec(resource $ch): This executes the curl resource and responds with the values from the server side.

43 Void curl_close($ch): closes the curl session and frees all resources. (Group, 2013) Examples <?php //HTTPS url to the code behind where the data is processed. $url = ' $_SESSION['ytunnus']. '?lang='. $_SESSION['lang']; //Initialize curl $client = curl_init($url); curl_setopt($client, CURLOPT_RETURNTRANSFER, 1); //SSL verification set to true curl_setopt($client, CURLOPT_SSL_VERIFYPEER, true); /* 0: Don t check the common name (CN) attribute * 1: Check that the common name attribute at least exists * 2: Check that the common name exists and that it matches the host name of the server */ curl_setopt($client, CURLOPT_SSL_VERIFYHOST, 2); // Certificate is necessary to communicate with the code behind curl_setopt($client, CURLOPT_CAINFO, "C:\\xampp\\apache\\conf\\ssl.crt\\server.crt"); $response = json_decode(curl_exec($client), true); curl_close($client);?> Figure 25 Curl GET request Figure 25 shows an example of the implementation. This example is a GET request to the server side code. The curl_exec($client) returns the output of the code behind, this output is in a JSON format. The JSON format will be discussed in section

44 44 <?php //HTTPS url to the code behind where the data is processed. $url = ' $_SESSION['ytunnus']; //Pass the data that the user has entered $data = json_encode(array("from" => $_POST['startdate'], 'to' => $_POST['enddate'])); //Initialize curl $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $data); //SSL verification set to true curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); /* 0: Don t check the common name (CN) attribute * 1: Check that the common name attribute at least exists * 2: Check that the common name exists and that it matches the host name of the server */ curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); // Certificate is necessary to communicate with the code behind curl_setopt($ch, CURLOPT_CAINFO, "C:\\xampp\\apache\\conf\\ssl.crt\\server.crt"); //Parse the values that are received of the API $response = json_decode(curl_exec($ch), true); curl_close($ch);?> Figure 26 Curl POST method Figure 26 shows a POST request. The data send to the server is in JSON format, and the answer is also in a JSON format and processed as an array.

45 45 <?php $url = ' $fh = fopen('data.txt', 'r'); $data = file_get_contents('data.txt'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_PUT, true); curl_setopt($ch, CURLOPT_INFILE, $fh); curl_setopt($ch, CURLOPT_INFILESIZE, strlen($data)); curl_exec($ch); curl_close($ch);?> Figure 27 Curl PUT method(sandoval, 2009) Figure 27 shows how the PUT request is set up. The PUT method isn t used in this project. <?php $url = ' $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "DELETE"); curl_exec($ch); curl_close($ch);?> Figure 28 Curl DELETE method (Sandoval, 2009) Figure 28 shows how the DELETE method is possible with curl. The DELETE method is not used in this project

46 OpenSSL This project makes use of XAMPP 1.8.1, which is a program making it possible to run a webserver on one s own local machine. XAMPP uses Apache 2.3, MySQL , PHP 5.4.7, phpmyadmin , and the OpenSSL service To make use of the HTTPS with SSL, a certificate is necessary. Libcurl needs that certificate to make sure that sent data is encrypted. There is by default no certificate available with the installation. To make sure that the certificate is correct, some commands are necessary. >opensslgenrsa -des3 -out server.key 1024 Figure 29 Generate a server.key Figure 29 shows the first command that generates the private server key. The next code generates the certificate signing request. >opensslreq -new -key server.key -out server.csr Figure 30 Certificate Signing Request Figure 30 shows the code line that asks the user for some configuration parameters. These parameters need to be well chosen, since if these are wrong the libcurl will not work. The last code line will sign the certificate. See Figure 31. >openssl x509 -req -days 365 -in server.csr -signkeyserver.key -out server.crt Figure 31 Sign the Certificate Afterwards, the certificate is made and the libcurl can use it. Before the libcurl can work the httpd-ssl.conf needs to be changed. In the conf-file the following parameters need to be changed: SSLCertificateFile "path/to/server.crt" SSLCertificateKeyFile "path/to/server.key"

47 When the conf-file is changed the server needs to reboot, after which the libcurl will work. (Pavan, 2009; Chng, 2009) OAuth Authentication Framework In a client-server model, authentication of the client to the server is an important issue. There are several ways to accomplish authentication, one of which is regular authentication by username and password. This is basic authentication good for basic website protection. When security is more important basic authentication is not enough; therefore, IETF (Internet Engineering Task Force) made an authentication framework called OAuth. The next paragraphs elaborate on different authentication methods and how OAuth works Principle concept Within a classic client-server authentication, the client wants to use access protected resources on the server, which is done by authentication with the server. The authentication happens with the credentials of the resource owner. As the resource owner shares its own credentials with the third party application, some problems and limitations arise: The resource credentials are stored in the third party applications for future use, often in clear-text. The servers have to support password authentication, even if this causes security weakness because of the passwords. The third-party application can have broad access to protected resources, without the resource being able to limit access to and duration of the resource. Resource owners cannot limit access of one third party without limiting access of all third parties, which can then only be done by changing the third-party s password. Changing any third party application will result in a change of the end-user s password and all the data that is protected by that password. (Hardt, 2012) OAuthwill deals with these issues by introducing an authentication layer, and making a separation between the client role and the resource. The client requests access to the resources through a resource server that is controlled by the resource owner.

48 48 The previous attempt to access resources used the resource owner s credentials, now the client gets an access token, containing the scope, lifetime and other access attributes. The access tokens are gained from an authentication server. In OAuth there are four important roles: Resource owner: The entity that is able to give access to the protected resources. Resource server: The server that owns the protected resources and is capable of accepting and responding to the requests for accessing the protected resources through access tokens. Client: The application that makes requests for accessing the protected resources, and this with authorization of the resource owner. Authorization server: The server that gives the access tokens to the client after a successful authentication of the resource owner and obtaining authorization. (Hardt, 2012) Handshake Figure 32 OAuth2 authentication flow (IdentityManagement, 2012)

49 Figure 32 shows how the authentication works for OAuth2 between the four roles. a) The client requests authentication from the resource owner. The client can get its authorization request directly from the resource owner or preferably indirectly via the authorization server. b) The client receives an authorization grant. This is a credential that stands for the resource owner s authorization, and represents one of the four grant types or an existing grant type. The type of grant type is depending on the method used by the client. c) The client asks for an access token by presenting the authorization grant and shows this to the authorization server. d) The authorization server checks if the client is authorized to access recourses and validates the authorization grant; if valid the access token is given. e) The client presents the access token to the resource server and asks for access to the protected resources. f) The resource server checks the validation of the access token and if its valid the server gives the client access to the resources. (Hardt, 2012) Authorization Grant There are several authorization grant methods. The different methods all have the same purpose: the client needs to have authorization to access the resources and this is done by obtaining an access token Authorization Code The authorization code is received from the authorization server that acts as an intermediate layer between client and resource owner. This means, that the authorization is not requested directly from the resource owner, instead the client is redirected to an authorization server that returns the authorization code to the client. The client never gets the resource owner s credentials, since this information is never shared. Instead the resource owner is authenticated with the authorization server and the authorization code is send through the authorization server to the client. (Hardt, 2012) The authorization code grant type is used to access and refresh the tokens. The client must be able to communicate with the resource owner s user-agent, because this grant is redirection-based flow. Moreover, the client must be able to receive incoming request that are redirected from the authorization server. (Gazit, Authorization Code Grant, 2012)

50 50 Figure 33 Authorization Code grant (Gazit, 2012) Figure 33 shows the flow of the authorization code grant type. These are the following steps: a) The flow is initialized by the client through the user-agent of the resource owner to the authorization endpoint. The client request includes the client identifier, requested scope, local state and redirection URI that is needed for the authorization server to send if the access is granted or denied. b) The resource owner is authenticated by the authorization server via the useragent. The authorization server establishes the connection if the resource owner grants or denies the client s access request. c) If the access is granted, the authentication server will redirect the user-agent to the redirection URI that is given by the client. The redirection URI contains the authorization code and previous state of the client. d) The client requests for an access token from the authorization server, this is done by including the authorization code that has been send in the previous step. The redirection URI that is used for getting the authorization code is verified by the client. e) In the last step the authorization server authenticates the client by checking the authorization code. If this is all valid the authorization server will respond with an access token and optional a request token. (Gazit, 2012)

51 Implicit grant 51 The implicit grant flow is a reduced version of authorization code flow. It is used for clients that use a browser with a scripting language like JavaScript. With implicit grant the client does not use an authorization code, it gets its access token directly. The grant type is implicit because there is no use of an authorization code. The authorization server does not authenticate the client by issuing the access token. The client can be identified by verifying the redirection URI that is used to deliver the access token to the client. (Hardt, 2012) Figure 34 Implicit grant flow (hansamann, 2012) Figure 34 shows the flow of an implicit grant type; the following steps are taken: a) The flow is initialized by the client through the user-agent of the resource owner to the authorization endpoint. The client request includes the client identifier, requested scope, local state and redirection URI that is needed for the authorization server to send if the access is granted or denied.

52 b) The resource owner is authenticated by the authorization server and this via the user-agent. The authorization server establishes the connection if the resource owner grants or denies the client s access request. c) If the resource owner grants access for the client then the authorization server redirects the user-agent back to the client redirection URI. The access token is included in the redirection URI. d) The user-agent makes a request to the web-hosted client resource by following the redirection instructions. The fragment information is retrieved locally by the user-agent. e) The web-hosted client resource returns a webpage that is able to access the redirection URI that includes the fragment. This fragment is gained from the previous step, which also includes the access token. f) The script is executed by the user-agent, and will extract the access token from the resource. g) The access token is then passed to the client. (Gazit, Implicit Grant, 2012) Resource Owner Password Credentials Grant The use of the resource owner password credentials (username and password) makes it possible to obtain an access token directly. This authorization type should only be used when the client and the resource owner have a trustful relation. This grant type makes a straight connection between the client and the resource owner to access the credentials of the resource owner. The resource credentials will only be exchanged for an access token. (Hardt, 2012) Figure 35 Resource owner password credentials flow (hansamann, OAuth2: The Resource Owner Password Flow, 2012)

53 Figure 35 shows the Resource owner password credentials flow, which consists of the following steps: a) The resource owner provides the client with a form to fill in his username and password. b) The client requests for an access token from the authorization server. In this request the client includes his credentials received from the resource owner. The client authenticates itself with the authorization server when it is making a request. c) The client will be authenticated by the authorization server and the server checks the validation of the resource owner s credentials. If the credentials are valid then an access token is given. (Gazit, Resource Owner Password Credentials Grant, 2012) Client Credentials Grant The client credentials can be used when the authorization scope is limited to the protected resources that are under control of the client, or when the resources are under control of a previously arranged resource owner. This grant type is used when the client acts as the client itself and as the resource owner. The client can ask for the access token using only the client credentials. (Hardt, 2012) Figure 36 Client Credentials flow (hansamann, OAuth: the Client Credentials Flow, 2012) Figure 36 shows the flow of a client credential grant type; the following steps are taken: a) The client authenticates with the authorization server and requests for an access token. b) The authorization server checks if the client can be authenticated and if this is possible the access token will be passed to the client. (Gazit, Client Credentials Grant, 2012)

54 Conclusion 54 The grant type that is most suitable for this project is authorization code, because here the client interacts with an authorization server through a user-agent. This is a secure way to make sure that the client is legit to access the resource. Another possible grant type is the Resource Owner Password Credentials, since there is a trustful relationship between client and server. In this project OAuth2 is not used, as it would take a database change, which is not possible Data representation When making a REST-fulAPI the resources have data associated with them. In order to represent the data, there are several ways of presenting data to the client. The ones that are used in this project are XML and JSON format. The next paragraphs will discuss more about these two formats Extensible Markup Language (XML) XML is an acronym that stands for Extensible Markup Language. XML has the advantage of being readable for both humans and machines. The focus of XML lies on being used for data structure. XML is used in different services and applications, and also in HTML to represent data in a structured way. A XML document starts with the document type declaration. It has a root tag and within this tag there are some child nodes. The next example (see Figure 37)shows the structure of a XML-file. (Bray, 2008) <?xml version="1.0"?> <note> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> Figure 37 XML example (Data, 2013) Moreover, a XML document also contains attributes with values.

55 Applied to the project 55 In this project the use of XML is possible, since the data was represented as a string value, and thus there were no complex data types. There are two ways to parse XML data files, SimpleXML and DOM. SimpleXML is used in this project to process the data given by the code behind file. The following example shows how the XML data is parsed. <?php //HTTPS url to the code behind where the data is processed. $url=' ='.$_SESSION['lang']; //Initialize curl $client=curl_init($url); curl_setopt($client,curlopt_returntransfer,1); //SSL verification set to true curl_setopt($client,curlopt_ssl_verifypeer,true); /* 0: Don?t check the common name (CN) attribute * 1: Check that the common name attribute at least exists * 2: Check that the common name exists and that it matches the host name of the server */ curl_setopt($client,curlopt_ssl_verifyhost,2); // Certificate is necessary to communicate with the code behind curl_setopt($client,curlopt_cainfo,"c:\\xampp\\apache\\conf\\ssl.crt\\ser ver.crt"); $response=curl_exec($client); curl_close($client); $responseutf8=utf8_encode($response); $xml=simplexml_load_string($responseutf8); foreach ($xml->transaction as $transaction) { $tapvm=htmlspecialchars($transaction ->tapvm); $saajannimi=htmlspecialchars($transaction ->saajannimi); $maksajannimi=htmlspecialchars($transaction ->maksajannimi); $summa=htmlspecialchars($transaction ->summa); $selite=htmlspecialchars($transaction ->selite); $viite=htmlspecialchars($transaction ->viite); }?> Figure 38 SimpleXML example Figure 38 shows how the XML is parsed with the function simplexml_load_string(). The string that was received was converted to UTF8 because the SimpleXML function does not support the ISO character set.

56 JavaScript Object Notation (JSON) JSON is an acronym that stands for JavaScript Object Notation. JSON is one of the ways that is used in this project. It is a data-interchange format, easy to read for both machines and humans. JSON contains three types of data: Scalar (number, string, Boolean, null) Array Object The scalar types are represented by a single value, arrays are an ordered list of values and objects are a collection of unordered set of key:value pairs, key is a string and value is an arbitrary type. (Jansen, 2011). The next example shows how a JSON object looks like: { "note": { "to": "Tove", "from": "Jani", "heading": "Reminder", "body": "Don't forget me this weekend!" } } Figure 39 JSON example Figure 39 shows the JSON version of the XML example, in this example it is also possible to nest multiple values. Here the values are all of the type string, which is not necessary Applied to the project The use of JSON representation is also possible to use in this project, though some changes are necessary to make it work. One of the advantages of using JSON is that it supports other types, like arrays, booleans, objects,.

57 <?php //HTTPS url to the code behind where the data is processed. $url=' $_SESSION['lang']; //Initialize curl $client=curl_init($url); curl_setopt($client,curlopt_returntransfer,1); //SSL verification set to true curl_setopt($client,curlopt_ssl_verifypeer,true); /* 0: Don?t check the common name (CN) attribute * 1: Check that the common name attribute at least exists * 2: Check that the common name exists and that it matches the host name of the server */ curl_setopt($client,curlopt_ssl_verifyhost,2); // Certificate is necessary to communicate with the code behind curl_setopt($client,curlopt_cainfo,"c:\\xampp\\apache\\conf\\ssl.crt\\server.crt"); $response=json_decode(curl_exec($client),true); curl_close($client); foreach($responseas$transaction){ $tapvm=htmlspecialchars($transaction['tapvm']); $saajannimi=htmlspecialchars($transaction['saajannimi']); $maksajannimi=htmlspecialchars($transaction['maksajannimi']); $summa=htmlspecialchars($transaction['summa']); $selite=htmlspecialchars($transaction['selite']); $viite=htmlspecialchars($transaction['viite']); }?> Figure 40 JSON code example 57 Figure 40 shows how curl example works with JSON. In this example the values that are received from the code behind file are decoded back to an array. This makes it possible to process the values as an array with named elements.

58 Conclusion 58 In this project the data is first processed as a XML format, but since there are some things to take in account when using XML a change is made to JSON. Some constraints to take in account when using XML: XML can be too rich in features, e.g. attributes and elements. An XML document can have elements with attributes and these elements can have subelements. This can cause confusion for the client and server side processing. XML has some limitations concerning types. When the system is using other types than just string to represent the data, XML is not a good way to handle that. If the XML is not well formed, the elements can be wrongly nested and this causes problems when processing the data. (Jansen, 2011).

59 4.6 MVC framework 59 When developing a web-based application the MVC framework makes its entrance quite soon. A MVC framework is a software architecture where there is a Model, View and a Controller. This architecture enables separation of the different functions of the system. The main concept behind MVC is the possibility of code reusability. (see Figure 41) Model View Return data Request data Return View Presenting data Controller HTTP Response HTTP Request End-user Figure 41 MVC architecture Model: The model stores the applications data objects, and does not know anything about the way data is shown to the end-user. The model has a straight connection to the database. It responds to the requests that are given by the controller and returns the data that was requested. View: The view presents the data that was received from the model to the end user. There are templates that can show the data, which are made in HTML, CSS and JavaScript. Controller: The controller responds to the different HTTP request, like POST and GET. The main function of the controller is to call and pass the right objects and data to the corresponding action. (Pastor, 2010)

60 60 In this project a MVC framework is was used. The MVC framework was Laravel 3. Laravel is a MVC framework that is developed by MIT. When the API was starting to grow and REST was more and more important, the framework wasn t capable to support the different constraints of REST. So to make the API with Laravel wasn t possible. The API was now made without the use of a MVC framework.

61 5 MATURITY MODEL 61 The development of a REST-ful API is not an easy task. There are some ways to check it the API or the framework actually is REST-ful. One good way to check this is to follow the Maturity Model of Richardson. It has 4 levels that describe how REST-ful the API is. When there is one constraint that is not fulfilled then the API cannot be called REST-ful. 5.1 Richardson Maturity Model Figure 42 Steps to RESTful API (Fowler, 2010) Figure 42 shows the different levels of the Richardson Maturity Model, each of these levels will be explained in the next paragraphs.

62 5.1.1 Level 0 62 At the beginning of this model HTTP is used as a transport system for remote interactions. The essential thing here is that HTTP is used as a tunnelling mechanism for the remote interaction with the server. (Fowler, 2010) (see figure 43) Figure 43 Level 0 example (Fowler, 2010) Figure 43 shows how the interaction works on level 0 of the Maturity model. Here the client wants to book an appointment with his doctor. The appointment software of the doctor does not know the schedule of the doctor in the hospital, so it makes a request to get that information. In level 0 of the maturity model the hospital will return the values in one URI. The same URI will be used to make an appointment. (Fowler, 2010) POST /appointmentservice HTTP/1.1 [headers] { "openslotrequest": { "-date": " ", "-doctor": "mjones" } } Figure 44 POST Appointment(Fowler, 2010) Figure 44 shows how the user POST an appointment.

63 The server responds with following answer (see Figure 45): 63 HTTP/ OK [headers] { "openslotlist": { "slot": [ {"-start": "1400", "-end": "1450", "doctor": { "-id": "mjones" } }, {"-start": "1600", "-end": "1650", "doctor": { "-id": "mjones" } } ] } } Figure 45 Response of Server(Fowler, 2010) The client can now book his appointment with the same URI that was send to the server the first time. (Fowler, 2010) see figure 46. POST /appointmentservice HTTP/1.1 [headers] { "appointmentrequest": { "slot": { "-doctor": "mjones", "-start": "1400", "-end": "1450" }, "patient": { "-id": "jsmith" } } } Figure 46 Book an appointment(fowler, 2010)

64 64 The server responds if the appointment is possible or not. In Level 0 of the maturity model, the data that has been send from and to the server are in plain old XML (POX), and the same URI is every time used Level 1 The next level in the Maturity Model is realised by using resources. Instead of requesting the information all through the same request, it is done with individual resources. (Fowler, 2010) (see figure 47) Figure 47 Level 1 adding resources (Fowler, 2010) If the client now wants to check for an appointment of a certain doctor he makes a request to a particular resource. POST /doctors/mjones HTTP/1.1 [headers] { "openslotrequest": { "-date": " " } } Figure 48 Request to a resource(fowler, 2010)

65 65 The server replies with the same information as in the level 0 (see figure 45). The difference is, that each slot is a resource, which makes it possible to address all of them individually. (Fowler, 2010) See figure 49 for the server response. HTTP/ OK [headers] { "openslotlist": { "slot": [ { "-id": "1234", "-doctor": "mjones", "-start": "1400", "-end": "1450" }, { "-id": "5678", "-doctor": "mjones", "-start": "1600", "-end": "1650" } ] } } Figure 49 Server response with resources (Fowler, 2010) So now the client wants to book an appointment to a certain slot. (see figure 50) POST /slots/1234 HTTP/1.1 [headers] { "appointmentrequest": { "patient": { "-id": "jsmith" } } } Figure 50 Client books an appointment with resource (Fowler, 2010)

66 The server replies in the same way as in level 0 see figure 51: 66 HTTP/ OK [headers] { "appointment": { "slot": { "-id": "1234", "-doctor": "mjones", "-start": "1400", "-end": "1450" }, "patient": { "-id": "jsmith" } } } Figure 51 Server Reply in level 1 (Fowler, 2010) In this level there is a possibility to use URI tunnelling and use just a single HTTP verb like POST Level 2 In level 2 of the model the HTTP verbs are introduced. The different HTTP response codes are also used in level 2. (see figure 52) Figure 52 Level 2 with HTTP verbs (Fowler, 2010)

67 When the client wants to get the doctor s slots, he makes a GET (see figure 53): 67 GET /doctors/mjones/slots?date= &status=open HTTP/1.1 Figure 53 GET request (Fowler, 2010) The reply of the server is the same as in POST method. When the client wants to book a new appointment this can be done with HTTP POST, this is the same as in level 1. The difference is now the server response. The server responds with a 201 Created to indicate that there is a new resource created. (see figure 54) HTTP/ Created Location: slots/1234/appointment [headers] { "appointment": { "slot": { "-id": "1234", "-doctor": "mjones", "-start": "1400", "-end": "1450" }, "patient": { "-id": "jsmith" } } } Figure response of the server(fowler, 2010) In the 201 response the location attribute is included, so the client can use this for accessing the resource in the future. If something goes wrong the server can respond with 409, which indicates that a conflict has come up. The level 2 introduces HTTP verbs and HTTP responses. (Fowler, 2010)

68 5.1.4 Level 3 68 Figure 55 Level 3 with the use of hypermedia controls (Fowler, 2010) The last level (see figure 55) is the most important level, it introduces Hypertext As The Engine Of Application State or HATEOAS. This tells the client how to get from a list of available slots the way how to book an appointment. The same GET method will be used as in level 2 (see figure 56): GET /doctors/mjones/slots?date= &status=open HTTP/1.1 Figure 56 GET method in level 3 (Fowler, 2010)

69 The response has now a new element in it: HTTP/ OK [headers] { "openslotlist": { "slot": [ { "-id": "1234", "-doctor": "mjones", "-start": "1400", "-end": "1450", "link": { "-rel": "/linkrels/slot/book", "-uri": "/slots/1234" } }, { "-id": "5678", "-doctor": "mjones", "-start": "1600", "-end": "1650", "link": { "-rel": "/linkrels/slot/book", "-uri": "/slots/5678" } } ] } } 69 Figure 57 HTTP response level 3(Fowler, 2010) Now each slot has a link element that contains the URI to tell the client how to book an appointment. (see figure 57) The idea behind hypermedia is that now the client knows what to do next and the URI is given with the resource. (Fowler, 2010)

70 70 If the client wants to book an appointment he can use the same post method as in Level 2 (see figure 58): POST /slots/1234 HTTP/1.1 [headers] { "appointmentrequest": { "patient": { "-id": "jsmith" } } } Figure 58 POST method level 3 (Fowler, 2010)

71 The server responds with a number of hypermedia controllers for different things to do next: 71 HTTP/ Created Location: /slots/1234/appointment [headers] { "appointment": { "slot": { "-id": "1234", "-doctor": "mjones", "-start": "1400", "-end": "1450" }, "patient": { "-id": "jsmith" }, "link": [ {"-rel": "/linkrels/appointment/cancel", "-uri": "/slots/1234/appointment" }, {"-rel": "/linkrels/appointment/addtest", "-uri": "/slots/1234/appointment/tests" }, {"-rel": "self", "-uri": "/slots/1234/appointment"}, {"-rel": "/linkrels/appointment/changetime", "-uri": "/doctors/mjones/slots?date= @status=open" }, {"-rel": "/linkrels/appointment/updatecontactinfo", "-uri": "/patients/jsmith/contactinfo"}, {"-rel": "/linkrels/help", "-uri": "/help/appointment"} ] } } Figure 59 Server response with Hypermedia controllers(fowler, 2010)

72 5.2 Other Maturity Model 72 This model evaluates how REST-ful a framework is. However, when writing a RESTful API the same levels have to be taken in account. (Pomares, 2012) Level 0 Not a REST-ful framework Level 0 means that the framework does not support REST Level 1 Mapping/routing and HTTP/URI encapsulation Level 1 provides two main aspects: A way to map the operations and the resources to methods and classes Encapsulate the complexities of the HTTP and the URI This level is similar to level 2 of the Richardson Maturity Model, it can accept HTTP requests and forward them to a method or a class. The framework can process the HTTP requests and responses with the corresponding HTTP codes. (Pomares, 2012) Level 2 Media Type Support and Client support When the framework can support media types it should be able to produce a representation of the resource using a known media type. This means, when the resource is send back to the client, it is send in e.g. XML or JSON format. The framework also needs to support multiple media types that can return resources as XML, JSON, HTML,... This is in regular HTTP the handling of the Accept header and error code 300 Multiple choices. The framework also needs to support clients, which can be done by: Adding client libraries to preform HTTP requests. Ability to read and process the representation in a given media type A way to negotiate the media type Client support is something that is only recently added to frameworks. But it is not a standard yet, so those frameworks are staying for a part in level 1.

73 5.2.4 Level 3 REST elements modelled into language 73 This level has improved support of HTTP requests, media type handling and client support. The REST concepts are modelled into the language semantics so the developer knows what the components, connectors and elements are. (Pomares, 2012) Level 4 Hypermedia as State Engine plus Semantic Support The framework should at least reach level 3 of this maturity model. In level 4 the framework should support the use of HATEOAS. This is one of the most important constraints of REST, because REST is made for the transfer of large hypermedia documents. The framework should at least support a link management in the documents. The links are used by the clients to decide where the state of the document should go. These links can dynamically be generated by the server. In order to help the client decide which link it should follow, metadata is used. The support of metadata should also be provided by the framework. This is important, since the client is then able to navigate between the different states using self-descriptive messages. (Pomares, 2012) Level 5 CoD and layering support One of the constraints of REST is Code on Demand. Because in level 4 the client needs to manage all the information types and the different messages, the demand of a super client is rising. The solution is that the server provides some code in form of a script. A second support type is layering, which requires a higher level of abstraction. This is out of the range of a single server or client; REST applications often require more than one server. The framework should be able to interact with other servers. (Pomares, 2012)

74 5.3 Conclusions and concerns 74 Richardson Maturity Model is a model that is a good representation of the different elements of REST. However, it is not a definition of the levels of REST itself. The only level when the API can call itself as a REST API is level 3, since, according to Roy Fielding REST APIs must be hypertext-driven otherwise it is not a RESTful API. (Fielding R., 2008) When the RMM is applied to the project API, it is concluded that the API is at level 1, as there is no HTTP response code processing. So if the server sends an error, the code will not process it. When applying the other maturity model, the API is at level 1 but the client is possible to process the data as an XML or a JSON format. So the API supports some of the media types. It does not support dynamical changing of the media types. In level 2 of the maturity model the API should support HTTP response codes. But it only supports the 200 OK response code. When evaluating the total API, the most suitable level for this project is Level 3. This is as then there is a way that the representation is handled through a class, and each resource has its own identifier. Also the HTTP response codes are processed by the class and it could handle all the errors as well. To summarize, it is concluded that the API that was built for this project is not a RESTful API. It uses some of the REST constraints, but to become a REST-ful API all of the constraints should be fulfilled.

75 6 General Conclusion 75 In this thesis the concept was to make a study of the architecture for a new web-based software system using a commercial ERP system. First I ve made a study of the different cloud systems. Each of these cloud systems have their pros and cons. But for this system there are two possibilities, using either a hybrid cloud. With a hybrid cloud they can keep their data private, and they have the advantage of a public cloud that is the expansion of the servers. The other possibility is that they still use a private cloud, so everything is managed by the administrators. The downside with private cloud is that the cost of expansion is bigger than with a public cloud. Then I studied the architecture style, REST and its constraints. When making an API with the use of a REST architecture style, it s important that all constraints are fulfilled. Otherwise the API can t be called a REST-ful API. The purpose of this thesis was to make an API that makes it possible to change the database without too much modification on the client side. The API that was build made an extra layer between the client and the server. So now it s possible to change the database from e.g. MySQL to Oracle without much problems. The architecture style REST is a very complex concept, this concept is not easy to apply in an API. But once the REST architecture is fully understood it s a powerful concept. 6.1 Future work To make an API REST-ful is not an easy task, but now the foundation of a REST-ful API is made. Regarding the thesis and the API, it s possible to make the API more REST-ful. Later on there will be more frameworks that support REST, so then it can be made with a MVC framework which makes the work of the programmer easier.

76 Bibliography 76 Abeysinghe, S. (2008). RESTful PHP Web services. Birmingham: Packt Publishing Ltd. Allamaraju, S. (2010). RESTful Web Services Cookbook. O Reilly Media, Inc. Anthony T. Velte, T. J. (2010). cloud computing a practical approach. MC Grawhi. Beaver, S. (2013, April 9). How Do You Define a Hybrid Cloud? Retrieved May 26, 2013, from The Virtualization Practice: Cloud-Computing-Solution1.jpg Bikeborg. (2013, May 23). File: Cloud_computing_layers. Retrieved May 25, 2013, from Wikipedia: png Borko Furht, A. E. (2010). Handbook of cloud computing. Springer. Bray, T. (2008, November 26). Extensible Markup Language (XML) 1.0 (Fifth Edition). Retrieved May 27, 2013, from W3C: Chng, P. (2009, May 5). Using curl in PHP to access HTTPS (SSL/TLS) protected sites. Retrieved May 25, 2013, from unitstep: cloudtweaks. (2012, April). Cloud Computing types of cloud and their relevance part 2. Retrieved May 26, 2013, from Cloudtweaks: Data, R. (2013). XML Tutorial. Retrieved May 27, 2013, from w3schools: doebertin, j. (2011, March 9). oauth mit XAMPP unter Windows nutzen. Retrieved May 5, 2013, from jonas-doebertin: Fielding. (1999, June). 14 Header Field Definitions. Retrieved May 23, 2013, from W3: Fielding, e. a. (1999). Status Code Definitions. Retrieved May 25, 2013, from W3 :

77 77 Fielding, R. (2008, October 20). REST APIs must be hypertext driven. Retrieved May 27, 2013, from Untangled: Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. UNIVERSITY OF CALIFORNIA. Fowler, M. (2010, March 18). Richardson Maturity Model. Retrieved May 28, 2013, from MartinFowler: Gazit, I. (2012). Authorization Code Grant. Retrieved May 27, 2013, from oauthlib: Gazit, I. (2012). Client Credentials Grant. Retrieved May 27, 2013, from oauthlib: Gazit, I. (2012). Implicit Grant. Retrieved May 27, 2013, from oauthlib: Gazit, I. (2012). Resource Owner Password Credentials Grant. Retrieved May 27, 2013, from oauthlib: Goodrich, G. (2012). php-logo. Retrieved May 25, 2013, from Roby Source: Group, P. (2013, May 24). curl Functions. Retrieved May 26, 2013, from Php: hansamann. (2012, July). OAuth: the Client Credentials Flow. Retrieved May 27, 2013, from techblog: Shot at AM.png hansamann. (2012, June 5). OAuth2: the Implicit Flow, aka as the Client-Side Flow. Retrieved May 27, 2013, from techblog: hansamann. (2012, June 5). OAuth2: The Resource Owner Password Flow. Retrieved May 27, 2013, from techblog: Hardt. (2012, October). The OAuth 2.0 Authorization Framework. Retrieved May 27, 2013, from IETF: IBM. (2005). Secure sockets layer overview. Retrieved May 23, 2013, from IBM: ame2.doc_5.1%2fss7aumst18.htm

78 78 IBM. (2012, November 1). An overview of the SSL handshake. Retrieved May 20, 2013, from IBM: IdentityManagement. (2012, May 15). OAuth2 into. Retrieved May 27, 2013, from IdentityManagement: Integration, E. C. (2012). History of Cloud Computing. Retrieved Maart 10, 2013, from EzeCastle Integration: Jansen, G. (2011). Resources. Retrieved May 5, 2013, from restful api design: K.roshan. (2011, August 28). What is Https and SSL? and how it works? Explained in Simple English. Retrieved May 20, 2013, from Techieinspire: Kepes, B. (2011). Understanding the Cloud Computing Stack. Rackspace. KUMARI, S. R. (2005). CLOUD COMPUTING: AN OVERVIEW. JATIT. Llc., 1. (2012, February 9). Who is responsible for security in the Cloud? Retrieved May 5, 2013, from 10Jumps: Luis M. Vaquero, L. R.-M. (2009). A Break in the Clouds: Towards a Cloud Definition. ACM SIGCOMM Computer Communication Review. Massé, M. (2012). REST API Design Rulebook. United States of America: O Reilly Media, Inc. Meijer, G. (2012, October 3). How to Build a Hybrid Cloud. Retrieved March 23, 2013, from CloudProviderUSA: Pastor, P. (2010, May 24). MVC for Noobs. Retrieved May 27, 2013, from Tutsplus: Pavan. (2009, February 14). opencodez. Retrieved May 26, 2013, from Create SSL Certificate and install in Xampp: PHP info. (n.d.). Retrieved May 25, 2013, from rubysource:

79 79 Pierobon, J. M. (2011, December). SSL Handshake Steps In Detail. Retrieved May 23, 2013, from pierobon: Pomares, W. M. (2012, April 4). Evaluating REST Frameworks Part 1: A Maturity Model. Retrieved April 8, 2013, from DeveloperFusion: Poretsky, S. (2013). SSL Limitations. Retrieved May 23, 2013, from Opposing views: Prakash, N. (2012, October 26). Did You Know Cloud Computing Has Been Around Since the '50s? Retrieved May 26, 2013, from mashable: Reese, G. (2009). Cloud Application Architectures Building Applications and infrastructure in the cloud. O'Reilly. Rhoton, J. (2010). Cloud computing explained: Implementation Handbook for Enterprises. Rp. Sameer Shelke, A. (2011, May 19). Microsoft Windows Azure Secure Development. Retrieved May 26, 2013, from CIO research Center: Sandoval, J. (2009). RESTful Java Web Services. Packt Publishing. sourya. (2011, February 9). A History of Cloud Computing. Retrieved May 26, 2013, from Cloud tweaks: Stenberg, D. (2013, May 25). Curl.1 the man page. Retrieved May 25, 2013, from Curl: Syed A. Ahson, M. I. (2010). Cloud Computing and Software Services Theory and Techniques. CRC press. TAMK. (2008). Kykylaakso. Retrieved March 20, 2013, from Kykylaakso: Torben Wilson, Z. G. (2001). PHP Functions Essential Reference. Sams. Weekly, C. (2009, March). A history of cloud computing. Retrieved April 3, 2013, from Computer Weekly: Wikipedia. (2013, May 20). HTTP Secure. Retrieved May 23, 2013, from wikipedia:

80 Wikipedia. (2013, May 18). Uniform resource locator. Retrieved May 24, 2013, from Wikipedia: 80