Download presentation
Presentation is loading. Please wait.
Published byKaren Campbell Modified over 8 years ago
1
© Donald F. Ferguson, 2014. All rights reserved. Topics in Computer Science: Modern Internet Service Oriented Application Development Some More on REST; API Management; SaaS Dr. Donald F. Ferguson Donald.Ferguson@software.dell.com (Admin: Kristina_Biehle@dell.com)
2
2 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Contents
3
3 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Contents Introduction –Survey feedback results. –Q&A, and discussion of 1 st assignment. –Getting a feel for a “real” top-level-design-specification A REST service continued –Some corrections: Compound keys, Media types/file extensions –Completing the functions –Asynchronous operations –Idempotency and Safety –Verbs –Updates –Events and notification New topics: Middleware, API Management/security and multi-tenancy/SaaS –Middleware –API Security
4
4 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Introduction
5
5 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Lectures and Class 29 responses. Avg = 3.9. Avg = 4.3
6
6 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Homework Complexity 29 responses. Avg = 3.3
7
7 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS General Comments I found the pattern of "explaining a term that appears in the middle of the explanation of another term" very difficult to follow. It would be really helpful if the lecture could be more well-structured, so that the terms are introduced in a way where previous ones build up to later ones. The current format cause my brain to overflow. It's so open ended that I am overwhelmed. I feel like I dont know where to start and the project writeup is confusing because I dont have an example from a previous class or something as a reference. I like being in class though. LEcture is interesting. i like the course so much since the professor is so nice and teach us very useful contents Please use less acronyms if possible. Thank you! if we could get more clear requirement of assignment, that will be better. Thanks Specifications of the hw is not very clear I think the class should move at a slightly faster rate. The material is really difficult and new for me. The lectures are very clear, although I do miss some details occasionally. I liked that you re- explained the security material three times because I was curious and confused. At the same time, I have many team members. I am worried that I will learn less in a big group, but programming any one section seems to require me to know all sections, so I am not sure what to think yet, except that I currently feel lost in the assignment, like some of my colleagues. In order to program the material, I have to learn it first. It's like climbing a mountain I can't see. I would really like it if the TA's provided a practical tutorial session or something to help us with our particular assignment. On the whole, this is an excellent class. I am learning much more than I could have ever expected, and sometimes it's good to be challenged. The instructions are not specific enough, most of time were spent on trying to figure out what to do I'm a EE student and don't have too much backgrounds in web development, maybe that's the reason I think it is too hard. By the way, if every team can have one or two who know the knowledge well, it will be helpful for the others to learn quickly. Unfortunately, my team doesn't have such people. Could professor consider that assigning maybe two CS students to every team?
8
8 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Observations and Actions General observations –The results are reasonably good, but not great. –Outliers –There are a couple of negative outliers that are not getting value from the lectures and do not think the course will be educational. –These people can contact me, and we can try to set up some separate guided project work in place of standard lectures and projects. Actions –TLDS template: Did more harm than good. I am going to look for a better template. –Homework –Obviously unclear to you despite being clear to me. –I am going to explain the assignments to the TAs, who will draft the HW definitions. –Ask questions. –Will be holding office hours.
9
9 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS First Projects Questions? Comments? Discussion?
10
10 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Skim through the TLDS Word document goes here.
11
11 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS 4+1 architectural view model http://en.wikipedia.org/wiki/4%2B1_architectural_view_model
12
12 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS The Architecture Views http://en.wikipedia.org/wiki/4%2B1_architectural_view_model Logical view : The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagram, Communication diagram, Sequence diagram. [2]Class diagramCommunication diagramSequence diagram [2] Development view : The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram. [2]Component diagramPackage diagram [2] Process view : The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagram. [2]Activity diagram [2] Physical view : The physical view depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagram. [2]Deployment diagram [2] Scenarios : The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as use case viewuse cases
13
13 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Some Diagrams
14
14 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Some Diagrams Class Diagram Communication Diagram Sequence Diagram Component Diagram Activity Diagram
15
15 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Agile Development and User Stories
16
16 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Documenting API Example URIhttps://mysite.com:3911/api/members/{id} HTTP verb PUT Parameters id : Card number of the member. Body name : Name of the member. email : Email adress of the member. langage : Langage used by member (Fr_CA ou En_US) Sample body { "name":"Mario Cardinal", "email":“mcardinal@mariocardinal.com", "language":"fr_CA" } Success Response Status Code: 204 No Content Error Response Status Code: 400 Bad Request, Body: {"Error Code":"..."} Status Code: 401 Unauthenticated, see WWW-Authenticate value in header Status Code: 403 Forbidden Status Code: 404 Not Found Status Code: 429 Too Many Requests, see Retry-After value in header Status Code: 500 Internal Server Error Status Code: 503 Service Unavailable Error Code 10: Inactive member 20: Denied access member 110: Database issues, Retry later
17
17 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Observations Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. Sr. Celestina: “If you cannot write it down, you do not understand it.” “it is a custom More honor'd in the breach than the observance” Hamlet Act 1, scene 4, 7–16 Comments –I have gone through a very systematic version of TLDS. –This model applies more to infrastructure SW than application SW. –All development projects do some flavor of this approach. –Just want to give you a feel for the types of things you can include in your TLDS, but you only need a really simple version and I am flexible. –Use common sense
18
18 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS REST Service Continued
19
19 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Corrections and Clarifications
20
20 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS REST and Compound Keys Consider a collection/table of students. There may be two ways to “get” a student. For example, J2EE defined “finder” methods. For example: –Student s = StudentHome.findByUni(“dff9”); –Student s[] = StudentHome.findByName(“Ferguson”, “Donald”); URIs/URLs –Unique key representation is obvious, e.g. …/api/students/dff9 –Compound keys is a little less clear. For example, 1.…/api/students/FergusonAll Fergusons 2.…/api/students/Ferguson/DonaldAll Donald Fergusons 3.…/api/students?lastname=Ferguson&firstname=Donald 4.…/api/students/Ferguson.Donald –My comments –(1) and (2) seem “Goofy.” –(4) is OK, and is analogous to the primary key approach –(3) is also OK. The issue is that the “web” would “cache” the result as two different resources for –…/api/students?lastname=Ferguson&firstname=Donald –…/api/students?firstname=Donald&lastname=Ferguson –I am OK with any approach as long as: 1) You are consistent. 2) Can explain the pros and cons of the choice you made.
21
21 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Let ’ s Think Back for a Minute Remember when I talked about REST “Uniform Interface?” This actually means Resource based –URIs identify (locate) individual resources. –The resources are representations and not the underlying DB schema, file data, … … Manipulation through representations –If I have a representation (may include headers) –I have enough information to reread, modify, delete (subject to security permission) the resource –And do not need “side information,” e.g. knowing that {“manager_id” : 21} needs to become …/staff/21. Self-descriptive: Each “message” contains enough information to process it, e.g. Content-Type
22
22 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Content Types A REST service may be cable of returning the answer in multiple formats, e.g. –JSON –XML –HTML How does the application making the GET specify the desired response type? –A strict interpretation of REST would have the client set the HTTP Accept header. –The general best practice is to use file extensions, e.g. –…/customers/21.html –…/customer/21.json –But this is not strictly REST because it is not self-descriptive using the uniform approach for HTTP. –But, standards for extensions are/will emerge.
23
23 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Remember The BLOB?! A GET on –…/staff/21/picture should return –The same kind of thing that you get when you click on –http://upload.wikimedia.org/wikipedia/commons/e/ee/Grumpy_Cat_by_Gage_Skidmore.jpg Content-Type: image/jpeg In the Express framework for node.js (http://expressjs.com/api.html) you can set this with the call res.type(‘image/jpeg’)http://expressjs.com/api.html Or just use Amazon S3
24
24 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Remember The BLOB?! This is kind of important.
25
25 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Headers – AJAX Example Referer – –The address of the server that gave you the resource –That had the URL you are accessing in it Content-Type == What you are sending. Accept == The formats you will accept in the response
26
26 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS REST Implementations Call REST Services Cart Functions Java SQLite Recommendation Functions Node.js Redis Catalog Functions PDP MongoDB XXX MMM NNN Content Functions Ruby Amazon S3
27
27 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Synchronous and Asynchronous HTTP operations are inherently synchronous –Connect –Verb –Response –Disconnect The implementation of the operation may “take a while,” –A calls B before returning. B calls C and D before returning to A. … –The implementation may be computationally or data intensive. –Something in the implementation may operate at “people speed,” e.g. –Creating an Account may require. –Manual approval by “Dave.” Holding open connections can cause problems –A server typically has an upper limit on open connections. Holding a connection for long requests will cause some client calls to “get a busy signal.” –A connection is more likely to break the longer it is open. A call graph of “long” connections is inherently fragile. One breaks and the whole thing breaks.
28
28 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Asynchronous Operation This is going to “take a while.” So, I am going to Tell you that your request looks OK. Acknowledge that I am working on it. Give you a URL on which you can poll with GET for the answer
29
29 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS 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 …/staff, …/stores –The data format in the table is {id, status, JSONString}, where JSONString is the response you would have received for a synchronous request. 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.
30
30 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS REST – Idempotent, Safe Definitions –Idempotency guarantees clients that repeating a request has the same effect as making a request just once. Idempotency matters most in the case of network or software failures. Clients can repeat such requests and expect the same outcome. –In HTTP, safe methods are not expected to cause side effects. … … Safety does not mean that the server must return the same response every time. It just means that the client can make a request knowing that it is not going to change the state of the resource. Observations –GET is pretty clear Read Only –PUT is sort of clear, but you need to implement –foo.setBalace(1234); and not –foo.debit(120); –DELETE is interesting –Both calls must respond either OK or not found. –The first call cannot respond OK, and the second one respond not found because the resource is deleted. –Unless these are two different DELETE requests –POST is baffling –I call POST and do not get a response. –You processed the message but the response got lost. –I call again. Did I create a duplicate? Does the second one respond “Is duplicate?”
31
31 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Headers – Some Choices We 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 Yes Conceptually similar to unique “hidden fields” in forms to handle clicking “submit” more than once
32
32 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS REST APIs Document Headers The “application” programming interface documents the business logic, e.g. –Create an address –Delete a customer –Set the movie’s due date to yyyy-mm-dd There are “things” that occur for all API calls, e.g. –Logging –Security checks –… … And you do not want to implement the functions over and over again in every API implementation {architected headers, middleware}
33
33 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Verbs Create—Retrieve—Update—Delete works well for a lot of application scenarios –Create a new address –Set the movie’s due date to yyyy-mm-dd –Delete the employee from the store’s staff There are some scenarios where this gets “icky.” –I want to “debit” $60. (Isolation) –I can read the balance (GET), subtract $60 and write (PUT). –But what if someone else changed the balance? –I want to transfer from a checking account to a savings account. (Atomic, Consistent) –Do I push all of the logic (R, R, W, W) onto all clients? –The data is “inconsistent” in between the 1 st and 2 nd write. There are two design patterns –Optimistic concurrency control (Isolation) –“Command” resources (Atomic, Consistent)
34
34 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS In Databases, Cursors Define Isolation We have talked about ACID transactions –Atomic: A set of writes all occur or none occur. –Durable: The data “does not disappear,” e.g. write to disk. –Consistent: My applications move the database between consistent states, e.g. the transfer function works correctly. Isolation –Determines what happens when two or more threads are manipulating the data at the same time. –And is defined relative to where cursors are and what they have touched. –Because the cursor movement determines what you are reading or have read. But, … Cursors are client conversation state and cannot be used in REST.
35
35 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Isolation/Concurrency Control There are two basic approaches to implementing isolation –Locking/Pessimistic, e.g. cursor isolation –Optimistic: Before committing, each transaction verifies that no other transaction has modified the data it has read. How does this work in REST? –The server maintains an ETag (Entity Tag) for each resource. –Every time a resource’s state changes, the server computes a new ETag. –The server includes the ETag in the header when returning data to the client. –The server may optionally maintain and return “Last Modified” time for resources. Semantics on updates –If-Match – value of a previous calls ETag response used with a PUT or DELETE. Server should only act if nobody else has modified the resource since you last fetched it. Otherwise provides a 412. –If-Modified-Since – value of a previous Last-Modified response used with a GET. Server should only provide a response if the resource was modified since the timestamp submitted. Use in conjunction with If-None-Match in case the change occurred within the same second. Otherwise provide a 304. –If-None-Match – value of a previous calls ETag response used with a GET. Server should only provide a response if the ETag doesn’t match, i.e. the resource has been altered. Otherwise provide a 304. –If-Unmodified-Since – value of a previous Last-Modified response used with a PUT or DELETE. Server should only act if nobody else has modified the resource since you last fetched it. Otherwise provides a 412
36
36 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Conditional Processing
37
37 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Request/Response
38
38 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Bob Already Read and now Updates In addition to updating the resource state, e.g. account balance, this also changes The ETag The Last Modified Date
39
39 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Now Mary Tries to Update Bob’s update changed the data, and changed this “metadata.”
40
40 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS OK. How does this work? I already have a database with collections and types –Do I modify the schema and add new fields? –Do I create additional tables that have the ETag and last time change? –… …? How you implement the semantics is up to you. The simplest ETag would just be a copy of the original data. –You gave me the value X for …/customer/21. –Update …/customer/21 to Y if the current value is X. The most common approach is –To have relatively coarse grain resources. –Compute a hash function of the resource data for the ETag. –On an update, –The incoming request contains the hash of what the client received. –The server reads the current value and computes the hash. –Update if the hash functions match.
41
41 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Verbs Sometimes, you really need a single operation that “consistently reads or manipulates” multiple resources, e.g. –Transfer $X from …/account/21 to …/account/13 –Please give me a list of all films in stock This requires –Implementing “commands” or “verbs” that are resources, e.g. –PUT on …/transfers and pass in JSON to, from accounts and balances –PUT on …/customer/21 that –Provides the information about the person –But also the address, which you want created at the same time. –Implementing common, pre-canned queries that span multiple databases, e.g. –Get all info about a customer, including address info. –Get all info about a store, including address info. –To avoid pushing lots of programming complexity for common tasks out onto every client application.
42
42 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Database Approach – Views and Stored Procedures
43
43 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Views and Stored Procedures The direct database implementation would use –Views –Stored procedures Applications typically write code (JavaScript, Java) that implements logic, making multiple database calls.
44
44 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Middleware
45
45 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Middleware Middleware is a computer software that provides services to software applications beyond those available from the operating system. For our purposes, there are two basic categories –An API and implementation that your code calls, e.g. –RDB, MongoDB –Naming service –Pub/Sub service –… … –Implicit capabilities that are woven into/injected into you application, e.g. –Authentication –Authorization –Nonce processing –Session management
46
46 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS “ Traditional Approach ” You would use an application platform like J2EE that comes with a standard set of middleware functions Your code can directly (or through a framework) call the middleware APIs You deploy your code into a container, which results in –Your business logic being “wrapped” by something –That implicitly calls middleware APIs “before” and “after” your business logic.
47
47 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS 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 …
48
48 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS New Model Start with a simple, lightweight runtime (e.g. Node.js) Your micro-service runs in the micro-runtime, and explicitly “uses” the implicit middleware services it requires, e.g. –Authentication –Logging –… … The callable middleware APIs are not themselves REST services –MySQL Amazon RDB –JMS Amazon SQS –… …
49
49 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Express Example Call local or cloud infrastructure APIs
50
50 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Evolve from Web UI to Publishing APIs
51
51 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS API Management
52
52 © Donald F. Ferguson, 2015. All rights reserved.Modern Internet Service Oriented Application Development – Lecture 3: Some More on REST; API Management; SaaS Where am I Going with This? You have already implemented this in the 1 st project You are going to implement “this” for four middleware services ETag/optimistic concurrency control (Simple) Authentication and authorization Logging Metering This is itself a service with a set of APIs that you will make available to the other project teams.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.