Design First is Better than API First

A presentation at PHP[TEK] in May 2019 in Atlanta, GA, USA by Lorna Jane Mitchell

Slide 1

Slide 1

Design-First is better than API-First Lorna Mitchell, Nexmo

Slide 2

Slide 2

It all begins with a story

Slide 3

Slide 3

UX Informs API Decisions All users have context, and this informs: • Style: REST, RPC, something else? • Format(s): JSON or XML (or a binary format …) • Authentication: pick a standard, e.g. OAuth • Error behaviour: application/problem+json • Collections: filtering, pagination • Hypermedia @lornajane

Slide 4

Slide 4

Write Decisions Down All stakeholders can access and contribute to documentation. @lornajane

Slide 5

Slide 5

Design Decisions There is no “right” answer, but BE CONSISTENT @lornajane

Slide 6

Slide 6

API Styles Most modern APIs are RESTful HTTP APIs. Also consider: • RPC APIs • Asynchronous APIs • Webhooks @lornajane

Slide 7

Slide 7

Data Formats Consider supporting more than one format. Don’t forget input formats as well as outputs! JSON XML { <message> Hello World </message> “message”: “Hello World” } @lornajane

Slide 8

Slide 8

Authentication Pick a standard, any standard! I prefer token-based schemes such as OAuth or JWT because: • they can be limited in scope or time • individual tokens can be revoked without affecting other tokens’ access @lornajane

Slide 9

Slide 9

Error Behaviour Must haves: • Consistent behaviour on all endpoints • Status code indicates success/fail • Data structure is predictable Nice to haves: • Link to further information • Use existing standard e.g. RFC 8707 https://tools.ietf.org/html/rfc7807 @lornajane

Slide 10

Slide 10

NAMING THINGS IS HARD Get feedback on naming for everything from everyone, all the time Be consistent! @lornajane

Slide 11

Slide 11

Designing Endpoints for REST • Is this a resource or a collection? • Which verbs make sense for this resource? • Is this collection something we nest inside the resource, or a separate collection? • /users/123 could nest all the user’s blog posts in a field • /users/123/posts as a separate to fetch all those posts • /posts?user_id=123 is also an option … then be consistent across the whole API @lornajane

Slide 12

Slide 12

Choosing Collaboration Tools @lornajane

Slide 13

Slide 13

Documentation Tools The best ones: • Work well with source control • Are quick to create documentation • Are easy to deploy • Are painless to maintain/update @lornajane

Slide 14

Slide 14

API Description Languages (this is a whole other talk) Description languages like OpenAPI make a machine-readable description of your API • It can be used to generate documentation • It can be used to fire up a mock server to play with • It can be used to import a collection into Postman • It can generate the basic outline of either the API server itself, or a client @lornajane

Slide 15

Slide 15

Best API Docs • Include a Quickstart for API-ready individuals • Include detailed tutorials for those who want them • Have detailed API reference materials Every API is someone’s first API @lornajane

Slide 16

Slide 16

The Impact of Design-First @lornajane

Slide 17

Slide 17

Consistency is key Implementation is a detail @lornajane

Slide 18

Slide 18

Resources • PHP Web Services (O’Reilly) • RESTful Web APIs (O’Reilly) • https://www.openapis.org • https://lornajane.net • https://benramsey.com • https://apievangelist.com @lornajane