© 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 A look at what is coming next

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 Implementing a Simple REST Service

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

13 © 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

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

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

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

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?

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

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

25 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Obvious URLs –…/staff Returns all staff –…/storesReturn all stores –…/paymentsReturn all payments –…/rentalsReturn all rentals –…/staff/21Return employee 21 –…/stores/11Return store 11 –…/payments/9You get the picture –…/rentals/6You get the picture But those keys are there for a reason –Links –…/stores/21/staff??? –…/payments/11/staff??? –…/stores/21/manager??? –Query limitations

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

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

28 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Contents Introduction –A little about me. –Course topics and schedule. –Assignments and grading. –Resources. Core Concepts –SOA, Web services, components. –Composite applications. –Examining the phrase “Modern Internet Service Oriented Application.” REST and SOA –Overview –Stateless, Idempotent –What can we learn from a relational datamodel? –Collections, keys, ad hoc query –Projection, partial update –Relationships and associations –Iteration, pagination –Metadata and reflection –Asynchronous operations –Events, notifications First assignment

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

30 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns A Little About Me … Career –Columbia –11 years as a student: B.A., M.S., M.Phil and Ph.D from Columbia University –Ph.D. Thesis – The Application of Microeconomics to the Design of Resource Allocation and Control Algorithms. –Previously taught 4 classes at Columbia –IBM –IBM Research for 10 years; IBM Software Group –Foundational work on web applications, J2EE and Web Services –IBM Fellow and Chief Architect for IBM Software Group –Microsoft –Technical Fellow –Technical strategy for future innovation in enterprise software –Initial work on BizTalk.net, and Integration-Platform-as-a-Service; Some concepts in Azure –CA technologies –Chief architect, Distinguished Engineer and CTO –Technical strategy and product architecture –Dell Software Group –Senior Fellow and CTO –Product architecture and technical strategy –Current focuses are cloud, cloud marketplaces, BYOD, IoT, iPaaS and next generation security Interests –Languages: Speak Spanish well. Learning Arabic slowly. Interested in linguistics and language theory. –Amateur astronomer –Road bicycling –Martial arts: Black belt in Kenpo karate; Krav Maga

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

32 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Assignments and Grading Grading –Grading will be based on –5, equally weighted, standalone team projects –5-6 page architecture/design paper. –Code review. –Demo. –You will provide a contribution percentage for each team member. –Class participation –Teams –Please form 4-5 person teams and let me know the members. –Send me an if you cannot find a team, and I will form some teams. –You may change team membership between projects. –I will take team size into consideration when assessing. We will not have a midterm or final.

33 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Resources Unfortunately, there is no textbook(s) –Books tend to be out of date. –The course is surveying multiple topics, which would require many books. –The web tends to be the best source of documents and tutorials. Some books –I will be using parts of SOA Patterns by A. Rotem-Gal-Oz ( ) for some early parts of the course. –The classics are –“Patterns of Enterprise Application Architecture” by Martin Fowler. –“Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions” by Holpe and Wolf. –“SOA Design Patterns” by Thomas Erl. – is a good, broad, shallow overview. –The best programmer I have ever known, and someone who mentors new programmers, recommended “Domain- driven Design: Tackling Complexity in the Heart of Software” by Eric Evans. I have not read this book.

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

35 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns SOA DEFINITION Service-oriented architecture (SOA) is an architectural style for build­ing systems based on interactions of loosely coupled, coarse-grained, and autonomous components called services. Each service exposes processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. A service’s behavior is governed by policies that are external to the service itself. The contracts and messages are used by external components called service consumers. Some observations – SOA is a reaction to distributed OO and RPC. –Coarse Grained and Messages –OO tends to lots of small classes/objects and fine-grain API calls (e.g. person.getIq()). –SOA tends to person.getState(). –Loosely coupled –Assume API calls “go remote” but may have local optimization. –Interfaces (Contracts) are not strongly typed, enabling independent evolution. –Endpoints –OO assumes “Java calling Java, perhaps over RMI.” –SOA separate Contract from Binding (WS-Interop, REST, message queues, etc). –Discoverable –OO assumes a classpath, findByClassName() and perhaps factory patterns. –SOA assumes you can go to a web callable repository and ask for SOA endpoints based on Contracts/Messages. –Web Services are a set of standards for SOA that enable interoperability.

36 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns SOA Various developer tools generate helper classes, allowing the programmer to focus on application logic and not details of formatting XML messages for SOAP. Services often go into containers that automate implementation of policies, e.g. transactions, security, reliable messaging.

37 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Composite Applications – Some Definitions “In computing, a composite application is a software application built by combining multiple existing functions into a new application. … A composite application consists of functionality drawn from several different sources. The components may be individual selected functions from within other applications, or entire systems whose outputs have been packaged as business functions, modules, or web services.” ( “Composition refers to a way of delivering enterprise solutions by assembling them from prebuilt components, instead of building them from scratch. It also includes personalization and customization abilities, so that users can easily and quickly modify specific functionality in the solution.” ( us/library/bb aspx) us/library/bb aspx “A composite application orchestrates independently developed programs, data and devices to deliver a new solution that none of the previously available applications could deliver on its own. Each resource accessed by a composite application uses a different data model. In most cases, the composite application supports user interactions beyond those provided by the leveraged applications. In other cases, a composite application may act as a service. Some composite applications are built by leveraging other composite applications.” (

38 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Composite Applications – Some Pictures

39 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Composites Start with Components

40 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Flexible Implementation – Some of which we will Cover

41 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns A Container: Application Server Architecture JNDI Sort of like DNS, but for APIs. Look up a provider of an API by a human name Resource Links The things I look up in JNDI. Configurable Instantiated connections JDBC JMS …

42 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Parsing the Course Title Modern Internet Service Oriented Application Development SOA –The same principles apply. –Evolving –From “coarse grained” meaning “big” to a lot of micro-services –Implemented using polyglot programming and persistence –Running in multiple, network addressable processes –That import the middleware functions they need versus being in containers. Internet –More natural usage of the Internet, e.g. –REST versus WSDL/SOAP –Google versus UDDI –Default web apps for API discovery versus WSDL. –And most of the business APIs and infrastructure APIs are “on the web.”

43 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Evolution Cart Functions Java SQLite Recommendation Functions Node.js Redis Catalog Functions PDP MongoDB XXX MMM NNN Content Functions Ruby Amazon S3

44 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Now – Much of what you need is “ on the web ”

45 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Now – Much of what you need is “ on the web ”

46 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns So, What are we going to study Technology for implementing services, e.g. –REST. –Various databases. –Web callable infrastructure, e.g. security, workflow. –Web callable business APIs. –Web/cloud friendly packaging and deployment, e.g. Docker. And “patterns” for “good implementation” –Implement basic services. –Assembly into composites. Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

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

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

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

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

51 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Representational State Transfer (REST) People confuse –Various forms of RPC/messaging over HTTP –With REST REST has six core tenets –Client/server –Stateless –Caching –Uniform Interface –Layered System –Code on Demand

52 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns REST Tenets Client/Server (Obvious) Stateless is a bit confusing –The server/service maintains resource state, e.g. Customer and Agent info. –The conversation is stateless. The client provides all conversation state needed for an API invocation. For example, –customerCursor.next(10) requires the server to remember the client’s position in the iteration through the set. –A stateless call is customerCollection.next(“Bob”, 10). Basically, the client passes the cursor position to the server. Caching –The web has significant caching (in browser, CDNs, …) –The resource provider must –Consider caching policies in application design. –Explicitly set control fields to tell clients and intermediaries what to cache/when.

53 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns REST Tenets Uniform Interface –Identify/locate resources using URIs/URLs –A fixed set of “methods” on resources –myResource.deposit(21.13) is not allowed –The calls are –Get –Post –Put –Delete –Self-defining MIME types (Text, JSON, XML, …) –Default web application for using the API –URL/URI for relationship/association Layered System: Client cannot tell if connected to the server or an intermediary performing value added functions, e.g. –Load balancing –Security –Idempotency Code on Demand (optional): Resource Get can deliver helper code, e.g. –JavaScript –Applets

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

55 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Anatomy of a URL SSOL for the Classlist 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 This is –Not REST –This is some form of Hogwarts spell –This is even bad for a web page

56 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Anatomy of a URL “server” containerHTTP:// …/ssol/…The module/component …/listManagerThe Application Object or …/Class/COMSE Entity Class (“Extent”) and ID.../WaitingList/…Contained Resource GET, POST, … on URLfor CRUD Some details –…/WaitlingList/dff9/IQPath navigation into resources –…/WaitlingList?op=“Approve”?CUID=“dff9”Method

57 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns What can we Learn from Data

58 © 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

59 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Some Concepts Foreign key relationships –Represent 1-1, 1-N relationships –Have “behavior,” e.g. –On Delete would prevent deleting a country if there is a city whose country_id is the country’s id. –On Cascade would automatically update all city.country_id when country.id changes Defining indices is important to avoid –Scanning the entire city table to –To find cities in a given country I would not put strings in a table for most words and string –Putting “Spain” for a country name –Prevents localization and national language enablement –Use symbols into localization resource bundles

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

61 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns What can we Learn? The implementation of the SOA contract/REST interface –Is a set of verbs on URLs –That manipulate a logical data model. Every logical data model has a common set of concepts that materialize through REST –ID  URI/URL –Collections supporting –Primary key  …/Customers/21 –Non-unique, secondary keys  …/Customers/Zipcode/12345 –Ad hoc query (SELECT WHERE (… …))  …/Customers?q=“id<=50&lastname=Ferguson” –Projection –SELECT iq, lastname FROM Customers  …/Customers?”Fields=iq,lastname” –UPDATE iq, shoessize WHERE …  PUT {{iq, “50},{…}}  …/Customers –Foreign keys/join tables  Hyperlinks –Iterators –SELECT * FROM Customers CREATE Cursor …  –GET …/Customers?Offset=40&Pagesize=20 –Thread/callback/promise  Asynchronous REST responses –Metadata/reflection: SQL DESCRIBE TABLE  Web UI for driving the REST API –Stored procedures  PUT…/Commands/… –Events/Notifcations  Feeds

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

63 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Implementation Observations Define a collection /QueuedResponses –A client can call …/QueuedResponses/21 to get a specific response. –You already know how to do this for …/Customer –The data format in the table is {id, status, JSONString} A simple implementation would be writing a façade –Accept request –Create new table entry with status = “in progress” –Return 202 and URL –Call the actual implementation –Update the database table entry with the JSON result Most application platforms have middleware approaches to support registering callbacks, threads, etc. The implementation would typically –Invoke some long running action, e.g. DB query, workflow process and register a callback –The callback implementation updates the entry in the response table.

64 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Ad Hoc Query Every collection should support ?q=“… …” –…/Customers?q=“lastName=21&IQ<21” –q is a string encoding a set of triplets with elements –Resource field, e.g. “lastName” –Comparison operation, e.g. “=“, “>”, … –Comparison value. Your code needs to –Parse and validate the query string. –Rewrite the string in the query language of the underlying database, e.g. Where clause in SQL –Execute the query –Refine the result set if the underlying database does not support query capabilities that you are surfacing through your API.

65 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Pagination {“data”: [{“user_id”:”42”, “name”:”Bob”, “links”:[{“rel”:”self”, “href”:” {“user_id”:”22”, “name”:”Frank”, “links”: [{“rel”:”self”, “href”:” {“user_id”:”125”, “name”: “Sally”, “links”:[{“rel”:”self”, “href”:” “links”: [{“rel”:“first”, “href”:” {“rel”:“last”, “href”:” {“rel”:“previous”, “href”:” {“rel”:”next”, “href”:”

66 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Implementation Considerations Query rewrite –…/Customers?q=“lastname=Ferguson&id<5”&limit=10&offset=5 –Neatly translates into an SQL statement –Select * from customers where … limit=5 offset=5 Other databases have similar concepts. You may have to –Rewrite a push the query down –Build a result cache in another store that supports limit/offset –Paginate through the cache You should also consider adding –“field=lastname,IQ,color” –To enable selecting a subset of fields

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

68 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Example Considerations Service Endpoint –Endpoint –Endpoint Encryption Requests and Authentication –Request Headers –Request Timestamps –Request Authentication –Response Headers Resources –Resource Requests –Resource Representation –Resource Methods –Synchronous Operations –Asynchronous Operations –Success Response Codes –Failure Response Codes Resource Data Types –Atomic Types –Complex Type - Object or Structure –Resource Relationships –Resource References Pagination –Through HTTP Link Header –Syntax and Example of Pagination Link Header –Consistency Across Page Requests Versioning –Version Header –Version URI Saying “REST is not enough You have to define a set of patterns/ conventions of URLs, headers, …

69 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Endpoint /a/b/c?x=7&y=21 is a pretty straightforward concept, but … –How do I get info about customer “Ferguson?” –…/Customer/Ferguson/Donald –…/Customer?lastName=“Ferguson”&firstName=“Donald” –??? –Do I really want to –Find info about Don using …/Customer/Ferguson/Donald –Find info about agent using …/Agents?id=“21” –How does it work if I can find customer by name or phone number? –How do I set a relationship between customer and agent? –PUT …/Relationship/AgentFor?agent=“21”&”Customer=“Ferguson” –Or two PUTS, one on Customer and one on Agent? In the same way you have to define a framework for your application, you have to define a shape/pattern in your REST API model.

70 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Headers – Some Choices I Made HTTP Request HeaderValueMandatory auth-timestamp:The current POSIX time.Yes auth-key: The user or client’s unique API KEY. Yes auth-signature: The HMAC-SHA256 digest for the request. Yes api-version:(Optional) API version stringNo Accept: (Optional) application/xml or application/json No Nonce:One time UUID to enable idempotency/duplicate detection

71 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Response Codes OperationHTTP RequestHTTP Response Codes Supported READGET OK with message body OK no message body OK with partial message body CREATEPOST Resource created (Operation Complete) Resource accepted (Operation Pending) UPDATEPUT Accepted (Operation Pending) Success (Operation Complete) DELETE Accepted (Operation Pending) Success (Operation Complete) Examples of Link Headers in HTTP response: Link: ;rel=monitor;title="update profile" Link: ;rel=summary;title=”access report” 202 means Your request went asynch. The HTTP header Link is where to poll for rsp.

72 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Failure Response Code ErrorResponse Code Invalid Parameter400 - Invalid parameter Authentication401 - Authentication failure Permission Denied403 - Permission denied Not Found404 - Resource not found Invalid Request Method405 - Invalid request method Internal Server Error500 - Internal Server Error Service Unavailable503 - Service Unavailable

73 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Design Pattern Choices Resource Requests Collectionhttps://ENDPOINT/NAMESPACE/RESOURCE[?QUERY_PARAMETERS] Resourcehttps://ENDPOINT/NAMESPACE/RESOURCE/RESOURCE_ID[?QUERY_PARAMETERS] Collection OperationHTTP Request Get all items in the collection GET /collection Should also return the URI of the collection itself. Get an particular item in the collectionGET /collection/itemId Get items match certain criteriaGET /collection?property1=’value’ Add a new item to the collection POST /collection contents of new item … Get items starting at 100 with page size=25 GET /collection?start=100&pageSize=25 Support for Map Array Collection

74 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Relationships {“membership”: { “URI” : “ “created” : “ T12:00:00.0Z”, “owner” : “user123456”, “expire” : “never”, “group” : { “ref” : “ }, “server” : { “ref” : “ } "link": { "href": " "rel": "self", “title” : “server-s123456” } Relationship as a resource Relationship as a field in resource

75 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Navigating Through Result Set GET on collections, maps, … needs pagination and cursors –Limit: What is the maximum number of elements you want? –QueryID: A tag for the query that produced the original result set –Offset references a specific element in a “page.” There is a standard for linking resources in logical sets, e.g. –Link: ; rel="previous"; title="previous chapter“> –Indicates that "chapter2" is previous to this resource in a logical navigation path. Your API/framework can use this for result sets –Example 1 –GET /api/customers?status=“Gold” returns some number of “Gold” customers and –Link Header for “next page” is Link: ; rel="next last“ –Which is the URL for the “cursor.next set,” which has 50 elements and is also “last” –Example 2 –Get returns the “next” from example 1 –With Link Link: ; rel="prev first" –Allowing you to go backwards to the previous “page.”

76 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns What ’ s Next?

77 © Donald F. Ferguson, All rights reserved.Modern Internet Service Oriented Application Development – Lecture 2: REST Details and Patterns Next Steps The first project will be (assign next week) –Implementing a well-designed REST API, e.g. –Sensible use of URLs and verbs –Handling links properly –Pagination –Partial get/update –Encapsulating a simple, but complex enough data model, e.g. –Primary keys, secondary keys –Foreign keys –Relational integrity semantics The next step for you is to –Set up a development/runtime environment, e.g. –LAMP –node.js –Play around with surfacing REST APIs and connecting to a database. We will start examining more complex topics once we can build a “component.”

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

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