Not all the WEB APIs are RESTful, some are just plain RPC.
REST is an architecture style.
The video attached to these slides.
https://www.youtube.com/watch?v=M28aBbtdWj4
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
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
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
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
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
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
It’s about decoupling and separation of concerns!!!
The text is the same, the visuals are different.
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.
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”.
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)
Web API as the public interface between two systems, the public contract.
What is REST?
It’s a lot more than HTTP Verbs and Resources, it’s a Software Architecture Style
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
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
With mobile RR is not efficient enough so pub-sub is coming (e.g. MQTT)
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.
Are we falling back to the old RPC way of thinking?