Slide 1

Slide 1 text

REST API Design Michael DeHaan NCSU, 2/2018

Slide 2

Slide 2 text

Why REST § Web services are especially popular § Cross-language support § Users know how to use it § Reduce documentation § Reduce coding of a separate API/UI path

Slide 3

Slide 3 text

Things To Watch For § Consistency in URLS, Error Codes, Search, Pagination § Id/URL as primary identifier § Discoverability § Security: Authorization, Authentication, Privacy § Testing

Slide 4

Slide 4 text

History § XMLRPC 1998, Dave Winer – Userland/Microsoft § SOAP 1998, Winer/various – Microsoft § REST 2000, Roy Fielding, UC Irvine

Slide 5

Slide 5 text

When § YES: External Facing Services § MAYBE: Internal Services § But Also: § Message Buses/Queues § gRPC/other

Slide 6

Slide 6 text

API Roots § http://example.com/ § http://example.com/api/ § http://example.com/api/v1/ § http://example.com/api/v1/bands/ § http://example.com/api/v1/venues/

Slide 7

Slide 7 text

Verbs § CRUD: § Create – HTTP POST § Retrieve – HTTP GET § Update – HTTP PUT § Delete – HTTP DELETE

Slide 8

Slide 8 text

Versioning § GET http://example.com/api/ Returns HTTP 200 { “versions” : { “1.0” : “http://example.com/api/v1” }, “current” : “http://example.com/api/v1” }

Slide 9

Slide 9 text

Discoverability § GET http://example.com/api/v1/ Returns HTTP 200 { “venues” : http://example.com/api/v1/venues, “bands” : “http://example.com/api/v1/bands”, ”shows” : “http://example.com/api/v1/shows” }

Slide 10

Slide 10 text

Read: Collections § GET http://example.com/api/v1/bands [ { id: 1, href: “http://example.com/api/v1/bands/1” name: “Van Halen” }, … ]

Slide 11

Slide 11 text

Read: Specific Records § GET http://example.com/api/v1/bands/1 { id: 1, href: “http://example.com/api/v1/bands/1” name: “Van Halen” }

Slide 12

Slide 12 text

Search § GET http://example.com/api/v1/bands/?genre=rock [ { “id:” : 1, “name” : “Van Halen”, “href” : http://example.com/api/v1/bands/1, “genre” : “rock” } ] --- POSSIBLY: GET http://…/bands?founded_lt=1990&genre=rock GET http://…/bands?founded_in=1997,1998

Slide 13

Slide 13 text

Sorting § GET http://example.com/api/v1/bands/?order_by=name [ { “id:” : 1, “name” : “Van Halen”, “href” : http://example.com/api/v1/bands/1, “genre” : “rock” } ]

Slide 14

Slide 14 text

Pagination § http://example.com/api/v1/bands?page=1&size=50 { “page” : 1, “count” : 500, “prev” : None, “next” : “http://….” “last”: 500 “items” : [ … ] }

Slide 15

Slide 15 text

Create § POST http://example.com/api/v1/bands { “name” : “Rush”, “genre” : “Rock”, … } RETURNS HTTP 201 { “id” : 2, “name” : “Rush”, … “href” : “http://example.com/api/v1/bands/2”, }

Slide 16

Slide 16 text

Update § PUT http://example.com/api/v1/bands { “name” : “Rush”, “genre” : “Prog”, … } RETURNS HTTP 200 { “id” : 2, “name” : “Rush”, … “href” : “http://example.com/api/v1/bands/2”, }

Slide 17

Slide 17 text

Delete § DELETE http://example.com/api/v1/bands/1 RETURNS HTTP 204

Slide 18

Slide 18 text

General Error Codes § 200-299 Ok § 300-399 Redirects § 400-499 User Error § 500-599 Server Error

Slide 19

Slide 19 text

Specific Error Codes § 200 OK § 201 Created OK § 204 Deleted OK § 302 Redirect § 400 Bad Request § 401 Unauthorized § 403 Forbidden § 404 Not Found § 409 Conflict § 500 Internal Server Error

Slide 20

Slide 20 text

Authentication (Humans) § POST /api/v1/login § { “user” : “bob”, “password” : “12345” } § => { ”session-ID” : “ABCDEFGABCDEFG” } § GET /api/v1/something_restricted § HEADER: § X-SESSION-ID: “ABCDEFGABCDEFG” § Backend looks for headers § Session table keeps track of last time token was used § Sessions not used for ~30 minutes may expire (auto-log- out) § Client handles re-login or keep-alive as needed

Slide 21

Slide 21 text

Authentication (Machines) § Use X-API-KEY from separate table

Slide 22

Slide 22 text

Authorization § Because you are logged in does not mean you can get something § Backend code must HTTP 403 as appropriate

Slide 23

Slide 23 text

Filtering § Private records § If not admin, maybe /api/v1/users should only return you § Private fields § Don’t return passwords

Slide 24

Slide 24 text

Testing § Most REST frameworks should allow § Run database setup § Call some method that simulates a JSON GET/PUT/POST/DELETE § Use database methods to see if rows are present § Check error codes § For each URL § Check all verbs/methods § Unauthorized user § Authorized user § Forbidden user § Invalid inputs § Valid inputs, correct results

Slide 25

Slide 25 text

Finishing Up § How To Tell If It’s Good § Discoverability, Consistency § Everything Is Paginated § UI can render any page of O(1), not O(n) § Actions and Weird Verbs § Jobs & Job Templates § Complex Endpoints for UI Simplicity § (Whiteboard Discussion)

Slide 26

Slide 26 text

Database Tips § Go to Ignacio’s Lecture! § Index any field you may search by

Slide 27

Slide 27 text

Questions/ Example? § Questions? § Let’s lay out an app?