© Donald F. Ferguson, All rights reserved. Topics in Computer Science: Modern Internet Service Oriented Application Development Dr. Donald F. Ferguson (Admin:

2 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Contents

3 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Contents Introduction –Questions, comments on lecture 1? –A comment on stateless and security. Implementing a REST service –Conceptual datamodel, “the old style of implementation,” and “the new way.” –Collections: primary key, secondary key, query –Relationships/Associations –Iterations –Projection –Update –Asynchronous operations –Events and notification First assignment

4 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Introduction

5 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Questions or comments from lecture 1?

6 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Security of Client Sending State S AliceBob S Eve Mal Eve steals information. Mallory changes information. Alice does not return what Bob sent.

7 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns A Note on Security There are several security considerations. Three important ones are: 1.Authentication: How does Bob know it’s Alice and vice-versa? 2.Privacy: What stops Eve from stealing info, e.g. account numbers? 3.Integrity: –What stops Mal from changing data, e.g. redirecting a deposit to a different account? –What stops Alice from maliciously changing the data? Simple answers (we will cover in more detail later in the semester) –Authentication: –Bob publishes and proves ownership of a digital certification. –Alice sends a user ID and password for logging into Bob. –Privacy: The communication occurs over encrypted HTTPS –Integrity: –Mal cannot read, and hence change, communication (including S) between Bob – Alice. –Alice does decrypt Bob’s responses because she needs to read the data. What stops Alice from being nefarious?

8 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Session Management Only Bob knows the secret.

9 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Comments Let’s assume that –S is string, e.g. serialized JSON object. –Bob may change S, but always returns value on every response. Bob and only Bob –Can encrypt and decrypt any string S with –Some function E(S, k) using the secret key k. Bob return a string S2 = E(S,k), not the actual data, to Alice.  Alice cannot even read the session state let alone modify. Bob can be even more secure …

10 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Bob can … Compute a hash H(S) using some algorithm –That has the property that S1 != S2  Pr[H(S1) = H(S2)] < –Bob can compute H(S) and then E(H(S)) and –Returns {S, E(H(S))} to Alice, which she must return. She can change S and “guess” a change to E(H(S)) but does not know the secret. –Bob recomputes when receiving Alice’s next message containing S1 Bob runs the algorithms –If S1 != S than probably –H(S1) != H(S) and almost certainly –E(H(S1)) != E(H(S)) Bob can use just encrypted hash if he only cares about Integrity. Bob can also salt the data (add a random, big string) to avoid cryptographic attacks that can break messages that –Are short –Have recurring information, e.g. {{user id, PW}, {account, 1234}} The Allies were able to break Enigma partly because –The first message sent with the new key for the day was short and always contained “Hi. This is XXX. Situation is normal.” –And because Enigma was not completely random. Enigma would never map A->A or B->B. –So, if you knew there was a “Crib” C that occurred in the space place in S –You could ignore possible wire/plug settings that would ever result in E(C[i]) = C[i]

11 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Where did this Come From? bin/ssol/DhbtiwfsFOMOeFQaDwqxAh/?p%.5Fr%.5Fid=k0F2vZ4ccAhzbcAg0Ql K4h&p%.5Ft%.5Fid=1&tran%.5B1%.5D%.5Fentry=student&tran%.5B1%.5D%. 5Fterm%.5Fid=20143&tran%.5B1%.5D%.5Fcid=COMSE6998&tran%.5B1%.5 D%.5Fsecid=005&tran%.5B1%.5D%.5Fsch=&tran%.5B1%.5D%.5Fdpt=&tran %.5B1%.5D%.5Fback=&tran%.5B1%.5D%.5Ftran%.5Fname=scrs Some history –Some browsers did not support cookies or handle them consistently –So, putting the session in a cookie (header) was fragile –The alternative was URL rewriting – becamehttp://myapp.me.org/students/21 – –Cookies/headers are most common now.

12 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Implementing a Simple REST Service

13 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Conceptual Datamodel “ Old Way ” “ New Way ”

14 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Database Model are Complex, even examples and samples, e.g. MySql Sakila Sample Database

15 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Customer Information

16 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Movie Information

17 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Stores and Staff

18 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Views and Stored Procedures

19 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Traditional Web Application 7. Select templates based on result, and pass data 8. Generate HTML result. Request Handler BOBO DB 1. HTTP GET/POST/… 2. Parse and validate request 3. Retrieve session context/info 4. Select “business object.verb base on GET/POST data and context info. 5. Access/Update DB through framework 6. Application logic 9. Send HTML response

20 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Traditional Way Develop a set of POJOs that implement core functions, e.g. –Submitting the “create customer form” will –Check for duplicates and conflicts –Determine if this is a new address or a new customer at an existing address –Submitting the “find rentals by telephone number” will –Find all the customers that have the given phone number –Then find all rentals for each of the customers –Merge and return the results The design relies heavily on database functions and a single logical DB, e.g. –A single POJO can find customers by phone number, and then loop through the result one customer at a time to find the rentals. –The database referential integrity constraint will prevent me from deleting an address if there is a customer at the address. –I can use a column in one table to find something in another.

21 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns New Model Service Reference ?

22 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns New Model We already talked about “coarse-grained” evolving into a –Set of “micro-services” –Implemented with polyglot programming and polyglot persistence So, what are some things we can learn about REST and this scenario –A uniform approach to CRUD on tables was awesome! Life would have been more unpleasant if every table had a different query language. –Linking “things” moves from linking at the DB level to linking across the web. –Exactly how does referential integrity work? –The micro-service for customer information management –Does now know in advance that it will be part of a rental app –And cannot know to “not delete” a customer if the customer has an active rental –Applications surface API for –Manipulating the information and defining the structure of the information. –How does somebody “Alter Table” when apps evolve?