REST != WebAPI
Download as PPTX, PDF1 like649 views
The document discusses the principles and architecture of web APIs and REST (Representational State Transfer), emphasizing client-server communication, design guidelines, and architectural styles. It outlines the components of a web page, including HTML, CSS, and JavaScript, and addresses the constraints of REST that enhance scalability and reliability. The importance of understanding integration patterns and involving stakeholders in deployment concerns is also highlighted, along with a call to create tailored architectural styles to meet specific needs.
![Client – Server Communication
Browser Server
HTML, CSS, JS
Data
Request
HTML, CSS, JS
Data
Response (HTML, CSS, JS)
Request Data
Response (JSON, XML)
GET https://api.example.com/Physicians?name=Smith HTTP/1.1
CorrelationId: 12AF3898-0C1E-4DC4-A1DB-92F65D85B2AB
HTTP/1.1 200 OK
Content-Type: application/json
[ {
"PhysicianKey": 12345,
"LastName": ”Smith",
"FirstName": ”John",
”PrimarySpecialty": ”Internal Medicine”
}]
IASA Pillar: Design
6](https://image.slidesharecdn.com/aeb15238-10a3-470c-b348-a577b109a974-151021182242-lva1-app6891/85/REST-WebAPI-6-320.jpg)
REST != WebAPI
- 1. REST != Web API Dan (Danut) Prisacaru, IASA CITA-A Sr. Principal Engineer https://www.linkedin.com/in/danut https://philosoftware.wordpress.com/ Software Philosopher Are we speaking the same language? IASA Pillar: Human Dynamics 1
- 2. •Web APIs •REST •Patterns and Tools •… 2
- 3. What makes a Web Page http://www.csszengarden.com/ IASA Pillar: Design 3
- 4. What’s in a page? SPA (Single Page Application) 1. HTML – HyperText Markup Language – is the standard markup language used to create web pages 2. CSS - Cascading Style Sheets is a style sheet language used for describing the look and formatting of a document written in a markup language. 3. Java Script – (ECMAScript) is a dynamic programming language used as part of web browsers, whose implementations allow client-side scripts to interact with the user, control the browser, communicate asynchronously, and alter the document content that is displayed 4. Data - ??? IASA Pillar: Design 4
- 5. Web Application Architecture Client – Server Architecture • The same Server provides the data • Different kind of clients can consume it • Browser on a laptop • Browser on a smart phone / tablet • Native app on a smart phone / tablet • Another Server • Client specification can require a different kind of UI • Data behind may not need to change API – Application Programming Interface – set of routines, protocols and tools for building reusable software components. Web API – set of routines, protocols and tools for building reusable software Web components. IASA Pillar: All => Architecture 5
- 6. Client – Server Communication Browser Server HTML, CSS, JS Data Request HTML, CSS, JS Data Response (HTML, CSS, JS) Request Data Response (JSON, XML) GET https://api.example.com/Physicians?name=Smith HTTP/1.1 CorrelationId: 12AF3898-0C1E-4DC4-A1DB-92F65D85B2AB HTTP/1.1 200 OK Content-Type: application/json [ { "PhysicianKey": 12345, "LastName": ”Smith", "FirstName": ”John", ”PrimarySpecialty": ”Internal Medicine” }] IASA Pillar: Design 6
- 7. Web API Guidelines PayPal API Style Guide https://github.com/paypal/api-standards/blob/master/api-style-guide.md 7
- 8. Web API Guidelines - continued Heroku – API Design Guide https://github.com/interagent/http-api-design 8
- 9. 9
- 10. •Web APIs •REST •Patterns and Tools •… 10
- 11. REST: Let’s start with Chapter 5! https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm CHAPTER 5 Representational State Transfer (REST) This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, while contrasting them to the constraints of other architectural styles. REST is a hybrid style derived from several of the network-based architectural styles described in Chapter 3 and combined with additional constraints that define a uniform connector interface. The software architecture framework of Chapter 1 is used to define the architectural elements of REST and examine sample process, connector, and data views of prototypical architectures. 5.1 Deriving REST The design rationale behind the Web architecture can be described by an architectural style consisting of the set of constraints applied to elements within the architecture. By examining the impact of each constraint as it is added to the evolving style, we can identify the properties induced by the Web's constraints. Additional constraints can then be applied to form a new architectural style that better reflects the desired properties of a modern Web architecture. This section provides a general overview of REST by walking through the process of deriving it as an architectural style. Later sections will describe in more detail the specific constraints that compose the REST style. 11
- 12. What is REST? Representational State Transfer https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Constrain Principle Advantage Trade-off 1. Client-Server Separation of Concerns • Improves the UI portability • Improves scalability • Allows the components to evolve independently 2. Stateless (server) • Improves: visibility, reliability, scalability • may decrease network performance by increasing the repetitive data 3. Cache (intermediaries) Improves • network efficiency • scalability • user perceived performance • can decrease reliability due to stale data 4. Uniform Interface (HTTP is too generic) Generality to the component interface • Simplified system architecture • Improves the visibility of interaction • degrades efficiency - information is transferred in a standardized form rather than one which is specific to an application's needs 5. Layered Systems Reduce system complexity • Layers can encapsulate legacy systems • Protects new systems from legacy clients • adds overhead and latency to the processing of data • reducing user-perceived performance IASA Pillar: Quality Attributes 12
- 13. Plato’s Theory of Forms The World of Ideas Danut’s REST John’s REST Chris’ REST The Perfect REST The Real World 13
- 14. Create your own Style!!! “We should be designing our architecture style to solve the problem we have and not just grabbing one because it’s the fad.” - Mike Amundsen 14
- 15. •Web APIs •REST •Patterns and Tools •… 15
- 16. Enterprise Integration Patterns (EIP) http://www.enterpriseintegrationpatterns.com/ In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. EIP Example Browser Server HTML, CSS, JS Data Request HTML, CSS, JS Data Response (HTML, CSS, JS) Request Data Response (JSON, XML) 16
- 17. Deployment Viewpoint Request-Response Integration Pattern This Viewpoint is meant to help solve the integration issues related to the Request-Response pattern for which we currently use the ESB/API Gateway A. Concerns When integrating two or more applications using the API Gateway, one needs to be concerned with how all the piece fall into place when deployed to production. The following is a list of possible questions that need to be addressed: 1. How does the URL need to be rewritten between different links in the chain of calls (hops over the network)? 2. In which Security Zone does every machine/server/network appliance sit? 3. How are the automatic failover / load balancing going to be addressed, in other words scalability? 4. How is the communication going to be secured (Firewalls, SSL, etc.)? 17
- 18. Deployment Viewpoint - Continued B. Stakeholders Make sure you involve the following stakeholders 1. Enterprise Technology 2. Information Security -> Authentication and Authorization 3. API Gateway Owners 4. Both the producer and the consumer of the services (Web APIs) 5. QA 6. Services & Business owners 18
- 19. Deployment Viewpoint - Continued 19
- 20. Deployment Viewpoint - Continued 20
- 21. Public Web APIs - Constraints Requirements: • Expose data for only one set of users • Authenticate the outside user with Single Sign-on • Authenticate the back end with the custom login • Cache the custom authentication token for N minutes to improve the latency and the user perceived performance • Use Site Registry Web API to locate the deployment • Provide logging to trace user’s usage and help troubleshoot problems 21
- 22. Tool: CA API Gateway (a.k.a. Layer 7) API Gateway Single Sign-on Web API Site Registry Web API 1. Authenticate User Login 3. Login Hard and Expensive to change Easier to change Cross Cutting Concerns Caching Splunk Logging 2. Locate Deployment 22
- 23. API Portal 23
- 25. •Web APIs •REST •Patterns and Tools •Conclusion 25
- 26. Conclusion REST as a Foundation We start here Web APIs as Public Contracts We need to get here Our Own Architecture StyleWe are missing this! 26
- 27. For More Information Dan (Danut) Prisacaru http://members.iasaglobal.org/members https://www.linkedin.com/in/danut https://philosoftware.wordpress.com THANK YOU !!! 27
Editor's Notes
- #4: It’s about decoupling and separation of concerns!!! The text is the same, the visuals are different.
- #5: 1, 2 & 3 – it’s about evolvability of different “concerns” How much do we care about data? Is the server just our “slave”? Before SPA (almost) everything was generated on the server. The “UI first” design approach dictates the interface between the Browsers and the backend when it comes to data.
- #6: Server to Server communication – one “kind of” Web API Client to Server communication – a different kind of Web API Should the server provide the same Web API to all? Is Content Negotiation the right solution? Some say that REST is “server driven” while the old SOAP/RPC way was client driven thus the “nightmare of versioning”.
- #7: The HTTP GET verb, the resource, the content-type, the rules to build them Resource /Physicians or GetPhysicians? PhysicianKey or PhysicianID? The Server is built using different: .NET, Java, PHP, Ruby, etc. => we need a common language MVC – separation of concerns => design * controller is a traffic cop – content negotiation – C selects the view * model is THE app * view is what serializes the data in a certain way: application / json for Web APIs (mostly)
- #8: Web API as the public interface between two systems, the public contract.
- #10: What is REST? It’s a lot more than HTTP Verbs and Resources, it’s a Software Architecture Style
- #13: Caching => Quality Attributes! Uniform Interface => Web API Heated on-line discussions about REST, was Fielding’s dissertation too “esoteric”. Should we define our own “pragmatic REST”? Some people do that but they still talk only about HTTP Verbs, resources as nouns, religious debate about versioning and so on. visibility, reliability, scalability => quality attributes => trade offs => you gain in one place, you compromise somewhere else. REST is for THE Whole
- #15: REST is too generic Stop whining and create your own. How about the Quality Attributes of your back end? “Why RMM Level-3 REST is not enough” Mike Amundsen – director of the API Academy, CA Technologies
- #17: With mobile RR is not efficient enough so pub-sub is coming (e.g. MQTT)
- #23: Web API servers had their own custom authentication mechanism. The API Gateway solve the impedance mismatch between the Single Sign-on and the custom auth.
- #27: Are we falling back to the old RPC way of thinking?