Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

What is RESTful? 2.0.0

No description
by

chris damour

on 30 October 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of What is RESTful? 2.0.0

RESTful
What is
RESTful
Architecture?

Why be
RESTful?

How to be
RESTful?

Why
so few
RESTful
Apps?

REST API
There's really no such thing
There is only
Application Architecture
Atrocities!
http://martinfowler.com/articles/richardsonMaturityModel.html
Level 3 APIs => Hypermedia APIs
or better
RESTful Application
Hypermedia Controls?
Identify available state transitions
FORMS
An awesome hypermedia control
Submit => transition state
The term REST API
is
an Atrocity
... but it's still pretty useful because people generally hear it and think: "a service that is
easy
to consume"
LINKS
An awesome hypermedia control
follow => transition state
The client of the Google Search App (the browser) never needed to construct a URL or know how to execute a search it just presents the hypermedia control to the actor (in this case a user)
RESTful Origin?
abridged version
Roy Fielding
What makes the web successful?
Because X, Y, & Z (etc)
Lots of work to re-explain X, Y & Z everytime
I'll call it RESTful!
RESTful Architecture
Definition
Simplified
An application is RESTful if it provides resources (being the combination of data + state transition controls) in a media type the client understands
It's All About Control
of the UX
UI
Shared UX means Consistent Clients
Flexibility For Change
Discovery
Product
Can't Add
Product Can Add
Add Result
Cart
UX
Discovery
Product Can't Add
Product Can Add
Add Result
Cart
UX Changes
Discovery
Product Can't Add
Product Can Add
Add Result
Cart
URL Changes
v1.0 owners & pets stored seperately in DB (normalized)
owner : /owners/<ownerId>/
pet : /pets/<petId>/
v1.1 pets stored with their owners (denormalized)
owner : /owners/<ownerId>/
pet : /owners/<ownerId>/pets/<petId>
Full Site
M-DOT
iOS App
Themed Site
Droid App
Win Phone
Content Negotiation
Hyper Resource Content Types
HTML
HAL+JSON
<html>
<head>
<link rel="profile" href="https://checkout.bodybuilding.com/profiles/step"/>
</head>
<body>
<form name="address-save" action="https://host/place/to/post/to" method="POST">
<fieldset name="shipping-info">
<legend>SHIPPING INFORMATION</legend>

<label for="name">First Name</label>
<input type="text" name="name" required="required" value="" maxlength="40"/>

<label for="country">Country</label>
<select name="country" required="required">
<option value="US">United States</option>
</select>

<label for="line1">Address</label>
<input type="text" name="line1" required="true" value="" maxlength="40"/>

<label for="city">City</label>
<input type="text" name="city" required="required" value="" maxlength="30"/>

<label for="region">State</label>
<select name="region" required="required">
<option value="RI">Rhode Island</option>
<option value="VT">Vermont</option>
</select>

<label for="zip">Zip / Postal Code</label>
<input type="text" name="zip" required="required" value="" maxlength="10"/>
<fieldset>

<input type="hidden" name="CSRF" required="true" value=""/>
<input type="submit" value="CONTINUE TO PAYMENT"/>
</form>
{
"sourceBranch": "origin/122.102-hot-fixes",
"sourceCommitId": "7f5806a10916809240854eb4313abef9b2a8d2e9",
"sourceCommitTime": "2015-05-07T10:11:11-0600",
"version": "1.122.102",
"buildTime": "2015-05-07T10:15:14-0600",
"_links": {
"profile": [
{ "href": "https://catalog.bodybuilding.com/profiles/root-catalog" }
],
"self": { "href": "https://catalog.bodybuilding.com/" },
"bb:hiring": {
"href": "http://hire.jobvite.com/CompanyJobs/Careers.aspx?k=JobListing&c=ql99Vfwi&v=1",
"title": "We're hiring!"
},
"bb:promotions": {
"href": "https://catalog.bodybuilding.com/promotions",
},
"bb:shop-by": {
"href": "https://catalog.bodybuilding.com/shop-by"
}
}
}
Link Anatomy
Links Have:
relationship (rel) [required]
href[required] - url of link target
name [optional] - secondary identifier. EG rel=pet,name=favourite
title [optional] - For display. EG: Fido
hreflang [optional] - US-en
type [optional] - application/pdf
HAL Extends Links into Templated Links:
relationship (rel) - IANA or URI
name [optional]
title [optional]
hreflang [optional] - US-en
type [optional] - application/pdf
templated - true
href - RFC6570 URI Template
Media Types Can Add Additional Behaviours to Conrtols
Many Hyper Media Types!
text/html
application/hal+json
application/atom+xml
application/vnd.mason+json
application/vnd.siren+json
application/vnd.collection+json
application/hal+xml
All they do is specify how to identify data & hypermedia controls!
Knowing What You Have
For a Client to be Reactive, it cannot assume anything about the response, so how can it identify what the response is?
2 possible answers
Use Content Types
Use Profile Links
Content-Type: application/vnd.product+hal+json
Somewhere documentation defines what a application/vnd.product+hal+json is and what data and controls it provides
I'm not a fan:
Namespace collisions
Not dereferencable -> where are the docs?
How do you provide mix-ins/traits? vnd.product+vnd.product-verifed+hal+json?
<link rel="profile" href="https://bb.com/profile/product"/>
The content type (eg text/html) defines how to locate link controls and retrieve profile rel links
Use link targets as URIs to determine what type of resource the client must react to.
Pros:
URIs -> avoid collisions
Dereferencable to Documentation
Traits -> just have multiple profile links!
It's simple, don't change URLS...but URLs invariably contain DB Keys
Hypermedia
Controls
Hypermedia Controls & identifiers
...well besides just about the entire non adobe flash web....?
So why so few RESTful APIs?
I think: knowledge + service tooling + client tooling
Keep Up To Date With Us!
@bbcomeng

@drdamour

http://techblog.bodybuilding.com/

https://github.com/bbcom

https://api.bodybuilding.com/store
making sure you speak the same hyper language
corollary: if your app only provides resources with no controls, it's an app that doesn't do anything! an
atrocity
Dr.
RESTful Client Apps
The Most Successful RESTful Client App in the World is the Web Browser!
Apps (ajax, angular, iOS, android, whatever!) need to be more like browsers!
Be Reactive: Never assume the result of the next state transition. Request the transition and REACT to the response!
Real World: Login Prompts, Errors, Validation Problems, UX Changes, Redirects, Outages, Push, A/B Tests
Techniques to Help Build Reactive RESTful Clients
When building a client app, think of it as a very fancy browser that allows for very sophisticated and interactive UIs. An uberbrowser.
If your Client app receives a Resource it doesn't understand [how to build a UI for], it may make sense to just send it over to the web browser.
Avoid putting a decision in your client app that your service app can make. It's generally simpler to deploy an updated Service than force updates on than client apps, especially native apps!
Backwards compatibility is a case of diminished returns. As the number of users on an old client approaches 0 the cost of maintenance increases. Ensure the very first release of your client app understands a resource that indicates the service requires the client to be updated. A forced upgrade.
Have the client app identify itself to your service app with a name and semantic version. This allows the service to provide compatible resources for a given version. This is better alternative to versions in URLs /api/v2/ or /api/v3. The http user-agent header is a godo mechnism for this, the baggage with user-agent sniffing are the worries of it's unreliability, but if your application requires it, it will be reliable.
goal: make your app as successful as the web!
An Atrocity,
Really?
An Atrocity because
the web never aims to be a REST API
(no, we haven't made a win phone app)
control identifiers
opaque URLs the client need not understand
opaque URLs the client need not understand
"_links": {
"some-rel": {
"href": "https://example.com/{path-param}/and{?query-param1,query-param2}",
"templated" : true
}
}
each with their own controls
presentation of state
transition of state
Building a RESTful service is not enough to reap the benefits of RESTful Architecture (be successful like the web!)
mr client
mr service
mr client
mr service
Chris DaMour
Principal Engineer Commerce
Joined BBCOM in March 2014
BBCOM: We Need Mobile Store Apps!
Me: I Just Got A Smartphone. They are really neat!
BBCOM: We Want A Consistent User Experience Between M-DOT, Fullsite, and Native Mobile Apps. This means the Same Features, Performance, Maintainability, & Business Control We Have Today. We
NEED
an API.
easy to parse (XML, JSON)
easy to identify (URLs)
easy to express intent (GET, DELETE, PUT)
easy to know what actions can be taken and how to execute them (????)
So Attempts Have Been Made to Qualify It...
An Atrocity Because of What We End Up Building
An API that
Generically
Exposes the Data
For Clients that Can Do
Whatever
They Want
All it takes is Reading Our Docs to Start
Constructing URLs
Treat
our API as if it is a File (the *nix credo)
We'll expose
Everything
as JSON
We'll expose
Everything
as XML
An Atrocity
Because of a Forgotten Timeline
2000
2005
2004
1999
2002
1996
We define web apps by what Actions they allow us to perform with the data they expose
We DO NOT define web apps by the Data they expose and URLs they expose them with
GET /search?q=nba
<li>nba.com</li>
<li>NBA - Twitter</li>
An Atrocity
Because We Shoupld Develop Applications not APIs
An API that can be used
Anywhere
An API is best considered a perspective form a Clients viewpoint. Limit the use of the term to that specific scenario.
An Application
a trip to plan
a book to buy
Provides data that can be acted upon, or
Resources
It is only when an external client consumes those resources that the application can be thought of as an API
You're an API!
that's what you think!
Fielding Starts Work on REST
MS Invents XMLHttp
REST Dissertation Published
Gmail Started
Gmail Public
Ajax Coined
Hearing REST API makes you cringe
Future
REST predates Ajax / JS Driven sites; therefore REST must not be only useful when buiding JS Powered sites.
There's a name for this: a
data feed
.
It can be USEful, but never RESTful
or
Because of the mindset at the start, you often end up building a big generic unoptimizable
atrocity
.
and it is probably not that much different than a database exposed on port 443 (please use https)
Avoid the atrocity: build apps that expose resources that define actions. Be
RESTful
Consider: a client dev can construct an insert statement from scracth just as easily as it can construct an HTTP request form scratch
state transition: an action performed by an actor that changes the current state. EG: acting upon data
aka
Forgiveness of Mistakes
aka
making real changes without breaking your clients
v2.0 New Ux
A Group
B Group
or A/B Test
Therefore a client that construct URLs that contain DB keys are tied to the way we index our data in the DB. A change to index method requires a change to clients
{
ownerId : 123,
pets : [456, 789]
}
{
self : "/owners/123",
pets : [
"/pets/456",
"/pets/789"
]
}
{
self : "/owners/123",
pets : [
"/owners/123/pets/456",
"/owners/123/pets/789"
]
}
Data Feed v1.0 & v1.1
RESTful Resource v1.0
RESTful Resource v1.1
A data feed client built for v1 will not be able to retrieve pets using v1.1
A RESTful client built for v1.0 still functions with v1.1
But changing the way you index data is an important optimization method (NoSQL?)
SCENARIO
control meta info
Choosing the Right Content Type
person
dog
owner
pet
link
form
link
link
templated link
embedded link
link
embedded link
templated link
link
collection
errors
link
entities
actions
link
attachment
files & schema
HAL does not have forms
HTML does not have template links
It is ok to use different content types for different resources in your applications.
For any resource choose the content type that has the controls needed to represent that resource best...but make sure it's RESTful!
data
control
application/json
application/hal+json
text/html
application/vnd.mason+json
odata (json)
odata (atom)
react native
Different content types have different controls. There is NOT a perfect all encompassing content type.
Be Reactive: Never require a previous state to achieve a subsequent state. IE don't require a product search to get to a product.
Mini Trainer Apps
CMS Widgets
_links :{}
_links, templated: true
_embedded : {}
<link>
<link templated="true">
<resource>
<link>
links : []
<link>,<img>, <a>
<form>,<input>
@controls : {}
Attachments : []
@controls.files|schema
collection : {}
error : {}
errors
@error : {}
classification
class : []
entities : []
actions : []
links : []
HAL indexes links by their relationship value. VERY useful!
state transition
<link rel="profile" href="https://bb.com/profile/product"/>
<link rel="profile" href="https://bb.com/profile/product-verified"/>
A Proposed Design for Reactive Clients
URL
Start with the URL
Turn it into a Resource
ResourceFactory(
)
Find and Bind to a View
ViewFactory(
)
or functionally
URL
.toResource().
toView()
Make it RESTful by using controls
Control
.toURL(
userInput
)
.toResource().
toView()
users use views to view a resource's data and invoke a resource's controls
this presentation
it's getting better
we are trying things
Hyperfit
Full transcript