REST APIs in the context of single-page applications

38
REST APIs in the context of single-page applications @YoranBrondsema August 25th 2014

description

Presentation given during the BRUG August 2014 meetup (http://www.meetup.com/brug__/events/194138762/). Covers the topics: - introduction to REST - authentication in REST APIs - authorization - how to use HTTP status codes - JSON API initiative (jsonapi.org)

Transcript of REST APIs in the context of single-page applications

Page 1: REST APIs in the context of single-page applications

REST APIs in the context ofsingle-page applications

@YoranBrondsema

August 25th 2014

Page 2: REST APIs in the context of single-page applications

About meCTO of Hstry

Organizer of Belgium Ember.js meetups

Page 3: REST APIs in the context of single-page applications

A bit of background application has a Ruby on Rails REST API and an Ember.js front-endHstry

Server-client communication is all JSON

API is not public: just one front-end

Page 4: REST APIs in the context of single-page applications

Today I'm talking about

1. What is REST?

2. Authentication

3. Authorization

4. HTTP status codes

5. JSON API

Page 5: REST APIs in the context of single-page applications

What is REST?Architecture for the World Wide Web

Page 6: REST APIs in the context of single-page applications

Separation of client and server

Page 7: REST APIs in the context of single-page applications

Stateless

Page 8: REST APIs in the context of single-page applications

Unique identification of resources through URIs

http://www.example.com/posts/15

Page 9: REST APIs in the context of single-page applications

Standard HTTP methods

GET

POST

PUT

DELETE

(PATCH)

Page 10: REST APIs in the context of single-page applications

Authentication

Page 11: REST APIs in the context of single-page applications

Implies some form of state

REST is stateless so stored on client

Page 12: REST APIs in the context of single-page applications

Token-based authentication

1. At login, generate token on server

2. Return token in response

3. Client includes token with every request

Page 13: REST APIs in the context of single-page applications
Page 14: REST APIs in the context of single-page applications

Where to store token?

Page 15: REST APIs in the context of single-page applications

In memory

Single-page application so no refreshes

Does not persist when user closes and opens tab

Page 16: REST APIs in the context of single-page applications

Cookies

Automatically sent with every request

Also sends other stored information

Stores text, not objects

Not very RESTful

Page 17: REST APIs in the context of single-page applications

sessionStorage and localStorage

Part of Web Storage specification

Secure, per-domain storage

Stores Javascript objects, not text

Stays on client

Send token through query parameter

Browser support is good ( )caniuse.com

Page 18: REST APIs in the context of single-page applications

All of this requires HTTPS!

Page 19: REST APIs in the context of single-page applications

Implementation in Devise, unfortunately...

Page 20: REST APIs in the context of single-page applications

Implementation vulnerable to timing attacks

Maintainer provided secure implementation, not yet merged in Devise (see )here

Page 21: REST APIs in the context of single-page applications

Authorization

Page 22: REST APIs in the context of single-page applications

Deals with permissions

Is User X allowed to perform Action Y?

Comes after authentication

Page 23: REST APIs in the context of single-page applications

Need context-aware DSL that is expressive enough

ALLOWED User with id 15 requests PUT /api/user/15/profile

FORBIDDEN User with id 16 requests PUT /api/user/15/profile

Page 24: REST APIs in the context of single-page applications

Define roles

e.g. admin, editor, user

Specify permissions for each role.

Page 25: REST APIs in the context of single-page applications

gemdeclarative_authorization

role :guest do ...end

role :student do # Include all permissions from guest includes :guest

has_permission_on :timelines, to: :show do # Can only see timelines that are made by himself if_attribute :type => is { "UserTimeline" }, :author => is { user } endend

Page 26: REST APIs in the context of single-page applications

HTTP status codes

Page 27: REST APIs in the context of single-page applications

Adds semantics to HTTP responses

Both for success (2xx) and error (4xx)

Page 28: REST APIs in the context of single-page applications

REST verbs

GET 200 OK

POST 201 Created

PUT 204 No content (200 OK if include response)

DELETE 204 No content

Page 29: REST APIs in the context of single-page applications

Error codes

Wrong authentication 401 Unauthorized

Wrong authorization 403 Forbidden

Parameter is missing 412 Precondition failed

Other error 422 Unprocessable entity

Page 30: REST APIs in the context of single-page applications

Nice overview on http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Page 31: REST APIs in the context of single-page applications

JSON API

Page 32: REST APIs in the context of single-page applications

jsonapi.org

Initiative by Steve Klabnik and Yehuda Katz

Standard for representation of JSON responses

Belief that shared conventions increase productivity through generalized tooling

Page 33: REST APIs in the context of single-page applications

Specifies...

...how resources are represented in JSON

{ "links": { "posts.author": { "href": "http://example.com/people/{posts.author}", "type": "people" }, "posts.comments": { "href": "http://example.com/comments/{posts.comments}", "type": "comments" } }, "posts": [{ "id": "1", "title": "Rails is Omakase", "links": { "author": "9", "comments": [ "5", "12", "17", "20" ] } }]}

Page 34: REST APIs in the context of single-page applications

...HTTP status codes and Location header

When one or more resources has been created, the serverMUST return a 201 Created status code.

The response MUST include a Location header identifying thelocation of all resources created by the request.

Page 35: REST APIs in the context of single-page applications

...structure for errors

{ "errors": [{ "id": "forbidden", "href": "http://help.example.com/authorization_error", "status": "403", "code": "ERROR_12345", "title": "Authorization error", "detail": "The requesting user does not have the permissions to perform this action" }]}

Page 36: REST APIs in the context of single-page applications

...structure for PATCH

PATCH /posts/1Content-Type: application/json-patch+json

[ { "op": "replace", "path": "/title", "value": "A new title" }]

Replace attribute title of resource /posts/1 with value A new title

Page 37: REST APIs in the context of single-page applications

Implementations

Ruby (0.9.0 released last Friday)ActiveModel::Serializers

Javascript Ember Data

... other languages too

Page 38: REST APIs in the context of single-page applications

Thank you