BEST PRACTICES FOR

DESIGNING SUPERIOR
RESTFUL APIS
Rohit Bhardwaj
Principal Cloud Engineer
[email protected]
Twitter: rbhardwaj1
 DESIGNING RESTFUL APIS
• RESTful APIs

• Hypermedia

• Principles for designing APIs

• SAML and OAuth

• Customer driven contract

• API testing
WEB API?
 RESTFUL APIS
• REpresentational State Transfer

• Separation of Client and Server

• Server Requests are Stateless

• Cacheable Requests

• Uniform interface
RESOURCE BASED
ARCHITECTURE
HYPERMEDIA
http://www.jayway.com/wp-content/uploads/2012/10/hypermedia-application.png
DESIGNING APIS
 REST-FUL URIS AND NON-
REST-FUL URIS

• /admin/updatebook.jsp?book=5

• /bookview.jsp?book=5

• /bookandreviews.jsp?book=5
NOUNS ARE GREAT! VERBS
ARE BAD
 WHAT IS SOLUTION?
• Prefer Plurals

• http://../api/Customers

• http://..//api/Employees

• http://..//api/States

• http://..//api/Orders
 IDENTIFIERS KEY

• http://../api/Customers/978

• http://..//api/Employees/emp123

• http://..//api/States/MA

• http://..//api/Orders/234
WHERE DOES VERBS GO?
WHERE DOES VERBS GO?
WHAT SHOULD YOU
RETURN?
RESOURCE
STATUS CODES
 HOW TO SATISFY
ASSOCIATIONS?
• http://../api/Customers/978/Orders

• http://..//api/Employees/emp123/Address

• http://..//api/States/MA/Cities

• http://..//api/Orders/234/Details
 RETURN SAME OBJECT

• http://..//api/States/MA/Cities

• http://..//api/Cities
 SAME OBJECT MULTI
ASSOCIATIONS

• http://../api/Customers/978/Orders

• http://../api/Customers/978/Shipments

• http://../api/Customers/978/Invoices
 WHAT IF YOU HAVE
COMPLEX ASSOCIATION?

• http://../api/Customers/state=MA

• http://../api/Customers/
state=MA&City=Chelmsford
 HOW TO FORMAT RESULTS?
• Use content Negotiation

• Accept header

GET /api/customers/987 HTTP/1.1

Accept: application/json, text/xml

Host: localhost:9876
MIME TYPES
 FORMATING
• http://.../api/Customers?format=json

• http://.../api/Customers.json

• http://.../api/Customers
format=jsonp&callback=foo
 JSON EXAMPLE
{  
         “id”  :  978  
         "firstName":  "John",  
         "lastName":  "Smith",  
         "age":  45,  
         "address":  
         {  
                 "streetAddress":  “21  Chelmsford  Street",  
                 "city":  "New  York",  
                 "state":  "NY",  
                 "postalCode":  "10293"  
         },  
         "phoneNumber":  
         [  
                 {  
                     "type":  "home",  
                     "number":  "987  555-­‐1234"  
                 },  
                 {  
                     "type":  "fax",  
                     "number":  "938  555-­‐3733"  
                 }  
         ]  
 }
 MEMBER NAMES

• Use camelCasing - Objects

 HANDLING ERRORS

• Learn writing code through errors

• Test Driven Development

• Troubleshooting and resolving issues

 ERROR HANDLING:
APPROACH 1
Facebook  
HTTP Status Code: 200
{"type" : "OauthException", "message":"(#803) Some
of the aliases you requested do not exist: foo.bar"}
Twilio  
HTTP Status Code: 401
{"status" : "401", "message":"Authenticate","code":
20003, “more info": "http://www.twilio.com/docs/
errors/20003"}
SimpleGeo  
HTTP Status Code: 401
{"code" : 401, "message": "Authentication Required"}
 BE VERBOSE AND USE PLAIN
LANGUAGE DESCRIPTIONS
• {"developerMessage" : "Verbose, plain language
description of the problem for the app developer
with hints about how to fix it.", "userMessage":"Pass
this message on to the app user if needed.",
"errorCode" : 12345, "more info”: "http://
dev.teachdogrest.com/errors/12345"}
 DESIGNING COLLECTIONS
{

“numberOfResults” : 6,

“retults” : [

“id” : 978

"firstName": "John",

"lastName": "Smith",

"age": 45,

"address":

"streetAddress": “21 Chelmsford Street",

"city": "New York",

"state": "NY",

"postalCode": "10293"

},

"phoneNumber":

"type": "home",

"number": "987 555-1234"

},

"type": "fax",

"number": "938 555-3733"

},

{…………… }]

}
 ENTITY TAGS (ETAGS)

• Header to support smart server caching

• Strong and Weak Caching

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2015 03:03:59 GMT
ETag: "10c24bc-4ab-457wer1f"
Content-Length: 12195
 ENTITY TAGS (ETAGS)
• Header to support smart server caching

• Strong and Weak Caching

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2015 03:03:59 GMT
ETag: "10c24bc-4ab-457wer1f"
Content-Length: 12195

GET /i/yahoo.gif HTTP/1.1

Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2015 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified

Use 304 to indicate object not modified

 ENTITY TAGS (ETAGS)

• Header to support smart server caching

• Weak Caching: Objects are semantically same

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2015 03:03:59 GMT
ETag: W/“10c24bc-4ab-457wer1f"
Content-Length: 12195
 PAGING TO RETURN
COLLECTIONS
• Prevent to return huge amount of data

• Large result sets performance

• Query String parameter to narrow down

• GET /customers?offset=10&limit=5
FILTERING
 FILTERING
• GET /customer/v1/user/orders?
from=01/12/2016&to=01/12/2016&sort=ascending&by=
…&index=0&count=20

• The equivalent long form is:

• GET /customer/v1/user/orders?where=”from=01/12/2016
and to=01/12/2016”&sort=ascending&by=…&
index=0&count=20
 BATCH CRUD OPERATIONS

• multi_create

• multi_read

• multi_update

• multi_delete
 I18NL10N

• Language

• Support ISO 639 Language codes

• Currency

• ISO 4217: Currency codes

 I18NL10N

• Numbers: Support Decimal XML Schema

• +2, -123.45, 0.34, 0

• Floats and doubles : IEEE 754-1985

• -1E4, 1234.43233E10, 12.78e-3, 13 , -0, 0

 I18NL10N
• Date/time: ISO-8601 standard

• Date: YYYY-MM-DD -> 2011-12-03

• Date and time: YYYY-MM-DD’T’HH:MM:SS -> 2011-12-03T10:15:30

• Time: HH:MM:SS -> 10:15:30

•
Chatty APIs: Bandwidth
Aware
Reduce chattiness

http://techblog.netflix.com/2013/01/optimizing-netflix-api.html
 PAGING

• {

"totalNumResults": 9999,

"nextPage": "http://.../api/customers/?page=5",
"prevPage": "http://.../api/customers/?page=1",
"results": [...]

• }
 PARTIAL ITEMS
• Query string to return less

• https://www.googleapis.com/demo/v1?key=YOUR-API-KEY

• https://developers.google.com/drive/v3/web/performance#partial-response
 API
• https://www.googleapis.com/demo/v1?key=YOUR-API-KEY
{

"kind": "demo",

...

"items": [

"title": "First title",

"comment": "First comment.",

"characteristics": {

"length": "short",

"accuracy": "high",

"followers": ["Jo", "Will"],

},

"status": "active",

...

},

"title": "Second title",

"comment": "Second comment.",

"characteristics": {

"length": "long",

"accuracy": "medium"

"followers": [ ],

},

"status": "pending",

...

},

...

 PARTIAL ITEMS
• https://www.googleapis.com/demo/v1?key=YOUR-API-
KEY&fields=kind,items(title,characteristics/length)
200 OK

"kind": "demo",

"items": [

"title": "First title",

"characteristics": {

"length": "short"

},

"title": "Second title",

"characteristics": {

"length": "long"

},

...

 NON RESOURCE APIS

• get support only

• Should be functional API

• http://.../api/calculatePrice?state=MA&total=62.95

• http://.../api/pingServer?isNotify=true

• http://.../api/weatherForecast?
isSummary=true&state=“MA”
 SUMMARY
• Do not surprise users

• Follow patterns available

• Caching and use Etags

• Use of Partial items

• Non Resource APIs

VERSIONING REST APIS
 WHY VERSIONING?
• Publishing an API is not a trivial move 


• Users/Customers rely on the API not changing 


• But requirements will change 


• Need a way to evolve the API without breaking existing clients 


• API Versioning isn't Product Versioning Don’t tie them together 


• Thy Shall not break existing Customers

http://zentofitness.com/wp-content/uploads/2011/07/breaking-chainsS.jpg
 EXAMPLES
• Uri Path

• Tumbler

• http://api.tumblr.com/v2/user/

• Uri Parameter

• Netflix

• http://api.netflix.com/catalog/titles/series/70023522?v=1.5

• Content Negotiation

• GitHub API

• ContentType:application/vnd.github.1.param+json

• Request Header

• Azure

•  x-ms-version:2011-08-18
VERSIONING IN THE URI PATH
• Using Part of Your Path to Version

• Allows you to drastically change the API

• Everything below the version is open to change

• Twitter

• http://api.twitter.com/1/users/show/noradio.xml

• Atlassian

• http://host:port/context/rest/upm/1/plugin/a-plugin-key
URI PATH
VERSIONING IN THE URI PATH
• Pro(s):

• Simple to segregate old APIs for backwards compatibility

• Con(s):

• Requires lots of client changes as you version 


E.g. version # has to change in every client 


• Increases the size of the URI surface area you have to support 

 VERSIONING IN THE URI
PARAMETERS

• http://api.netflix.com/catalog/titles/series/
70023522?v=1.5

• http://..//api/Employees

• http://..//api/Employees?v=3.1
 VERSIONING IN THE URI
PARAMETERS
• Pro(s):

• Without version, users always get latest version of API

• Little client change as versions mature

• Con(s):

• Can surprise developers with unintended changes

HYPERMEDIA CONTROL
VERSIONING WITH CONTENT
NEGOTIATION
• GET /api/employee/978

HOST: http://.../

Accept: application/myapp.v3.employee

• GET /api/employee/123

HOST: http://.../

Accept: application/myapp.v3.employee.json
 VENDOR TYPE VERSION THE
REQUEST TYPE
===>

GET /customer/123 HTTP/1.1

Accept: application/vnd.company.myapp.customer-v1+xml

<===

HTTP/1.1 200 OK

Content-Type: application/vnd.company.myapp.customer-v1+xml

<customer>

<name>Neil Armstrong</name>

</customer>
http://thereisnorightway.blogspot.com/2011/02/versioning-and-types-in-resthttp-api.html
 NEWER CLIENTS MAKE A
DIFFERENT CALL
===>

GET /customer/123 HTTP/1.1

Accept: application/vnd.company.myapp.customer-v2+xml

<===

HTTP/1.1 200 OK

Content-Type: application/vnd.company.myapp.customer-v2+xml

<customer>

<firstName<Neil>/firstName>

<lastName<Armstrong>/lastName>

<salutation>Mr.</salutation>

</customer>
VERSIONING WITH CONTENT
NEGOTIATION
• Pro(s):

• Packages API and Resource Versioning in one

• Removes versioning from API so clients don't have to change

• Con(s):

• Adds complexity - adding headers isn't easy on all platforms 


• Can encourage increased versioning which causes more code churning 


 VERSIONING WITH CUSTOM
HEADER
GET /api/customer/123

HOST: http://.../

x-MyApp-Version: 2.1
 ADDING DATE

GET /api/customer/123

HOST: http://.../

x-MyApp-Version: 2013-08-13
 VERSIONING WITH CUSTOM
HEADER
• Pro(s):

• Separates Versioning from API call signatures

• Not tied to resource versioning (e.g. Content Type) !

Con(s): 


• Adds complexity - adding headers isn't easy on all platforms

 WHICH ONE TO CHOOSE?
• There is no easy answer

• Versioning with Content Negotiation and Custom

Headers are popular now

• Versioning with URI Components are more common

• These are easier to implement

• But you should version from the first release of your API
• YOU MUST VERSION API !
API SECURITY
 SECURITY APIS
• Threats

• Protecting APIs

• Authentication

• API Keys: How they work?

• User Authentication and Authorization

• SAML

• Understanding OAuth
 WHY NEED TO SECURE?
❖ US laws and Regulations

❖ International laws and regulation

Privacy: KPMG Data life cycle
Data Security lifecycle
} wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
WHY PROTECT APIS?
• Server-to-Server Authentication

• API Keys and Shared Secrets

• User Proxy Authentication

• OAuth

• Direct User Authentication

• Cookies or token
• Credential:

• A fact that describe an identity

• Authentication:

• Validate a set of credentials to identify an entity (whether virtual or

actual)

• Authorization:

• Verification that an entity has rights to access a resource or action

Confidentiality: Symmetric Encryption :
Efficient

Data Accountability and

Trust Act, 2006

https://keybase.io/triplesec/
http://code.google.com/p/jscryptolib/
https://keybase.io/triplesec/
Confidentiality: Asymmetric Encryption

http://www.securecottage.com/demo/rsa2.html
http://support.persits.com/encrypt/demo_text.asp
http://support.persits.com/pdf/demo_encrypt.aspx
 AUTHENTICATING USERS

• Within system

• OAuth
OAUTH
Open Authentication (OAuth)

http://brentertainment.com/oauth2/
DOCUMENTATION
OAUTH AND SWAGGER
DEMO

http://petstore.swagger.io/#/
 JSON WEB TOKENS

https://jwt.io/introduction/

Compact and self-contained way for securely transmitting

information between parties as a JSON object
http://microservices.io/patterns/apigateway.html
API
HYPERMEDIA: LINKS IN API
JSON
RETURNING MORE ACTIONS
 HAL: HYPERTEXT
APPLICATION LANGUAGE

• HAL is a simple format that gives a consistent and

easy way to hyperlink between resources in your
API.

Amazon Chooses HAL Media Type for AppStream API

http://www.infoq.com/news/2014/03/amazon-hal-appstream
 http://stateless.co/hal_specification.html
http://haltalk.herokuapp.com/explorer/browser.html#/
http://martinfowler.com/articles/consumerDrivenContracts.html
http://techblog.newsweaver.com/why-should-you-use-consumer-driven-contracts-for-microservices-integration-tests/
API MANAGEMENT
TEST REST APIS
POSTMAN DEMO
 DESIGNING RESTFUL APIS
• RESTful APIs

• Hypermedia

• Principles for designing APIs

• SAML and OAuth

• Customer driven contract

• API testing