Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Building APIs
Search
Justin Yost
July 03, 2015
Programming
1
7.3k
Building APIs
Justin Yost
July 03, 2015
Tweet
Share
More Decks by Justin Yost
See All by Justin Yost
Laravel 6, 7 and Other Goodies
justinyost
2
85
PHP and Databases
justinyost
2
43
Ansible: What Is It and What Is It Good For?
justinyost
0
31
Generators: All About the Yield
justinyost
0
11
Laravel 6: What's New and What's Changed
justinyost
0
210
Middleware: Between the Framework and the Browser
justinyost
2
83
Caching and You and You and You and You...
justinyost
0
48
Git: The Pain and the Gain
justinyost
0
120
Generators: All About the Yield
justinyost
0
240
Other Decks in Programming
See All in Programming
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
260
DRFを少しずつ オニオンアーキテクチャに寄せていく DjangoCongress JP 2025
nealle
2
290
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
1.1k
はじめての Go * WASM *OCR
sgash708
1
110
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
310
kintone開発を効率化するためにチームで試した施策とその結果を大放出!
oguemon
0
190
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
9
2.5k
sappoRo.R #12 初心者セッション
kosugitti
0
280
読まないコードリーディング術
hisaju
0
110
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.6k
.NET Frameworkでも汎用ホストが使いたい!
tomokusaba
0
200
Introduction to kotlinx.rpc
arawn
0
770
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
134
33k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.4k
Designing Experiences People Love
moore
140
23k
RailsConf 2023
tenderlove
29
1k
Documentation Writing (for coders)
carmenintech
68
4.6k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Transcript
Building APIs Justin Yost Web Developer at Loadsys 4 twitter.com/jtyost2
4 github.com/jtyost2 4 yostivanich.com
What is an API 4 API - Application Programming Interface
4 One thing talks to another thing. 4 Twitter, Facebook, AWS, all have APIs.
Why do you need an API 4 JS Front End
Framework? 4 An app? 4 Talk to other servers than the ones you own/ provision?
Design 4 APIs are for developers 4 APIs are for
in-house developers 4 APS are for outside developers 4 APIs are for possibly all level of developers
https://stripe.com/docs/ api
APIs are hard
Key Tips For Designing an API 4 Consistency 4 Standards
(REST, HTTP, OAuth) 4 Versioning 4 Documentation (API Blueprint) 4 Don't just present the database
Consistency 4 Endpoints /people and /people/15 vs /person and /person/15
Consistency 4 Output { "people": { {"name": "First"}, {"name": "Second"}
} } vs { "person": { "name": "First" } }
Standards 4 REST 4 OAuth 2.0 4 JSON (JSON API
hit 1.0 recently)
REST Uniform Interface 4 System of endpoints 4 Provides enough
information to be self describing 4 Provides enough information to manipulate 4 The interface is HTTP itself
REST Stateless 4 HTTP is Stateless by design 4 Web
apps though tend to care about state 4 State is what stored information do I already know when you make the request (Session is State)
REST Cacheable 4 API should respond with Cache Headers as
appropriate 4 API Clients should respect Cache Headers
REST Client-Server 4 Separation of Concerns 4 Client - presents
data, protects user state 4 Server - stores data
REST Layered System 4 Clients may not always talk directly
to the API server 4 Talk to an Auth Server, then a caching server, then API server
Design REST 4 REST enforces a pattern
Design REST 4 REST is HTTP 4 HTTP is more
than GET, POST, PUT, DELETE 4 OPTIONS and HEAD 4 Idempotent Methods (GET, HEAD, DELETE, PUT) 4 Return Correct and Valid Headers
Design OAuth 2.0 4 http://oauth.net/2/ 4 https://aaronparecki.com/articles/2012/07/29/1/ oauth2-simplified 4 Short
URL: http://jty.me/1dEQyge 4 Support for a variety of authentication schemes 4 Tons of pre-existing libraries and packages
Design JSON 4 Use JSON 1st and primarily 4 Maybe
XML - are you a bank or law firm or Google? 4 Consider JSON API (Like really really consider it)
Design Versioning 4 /api/v1/foo 4 /api/foo HEADERS: {'api-v': '1.0'} 4
/api/foo HEADERS: {'Accept': 'application/ vnd.domain.v2+json'} 4 https://v1.domain.com/api/foo
Design Documentation 4 Clear 4 Complete 4 Examples (CURL, PHP,
Java, Ruby, Node, Go, etc)
Design Documentation 4 API Blueprint: https://apiblueprint.org/ # GET /message +
Response 200 (text/plain) Hello World!
Design Documentation 4 Dredd: https://github.com/apiaryio/dredd
Design Don't just present the Database 4 Database and API
are different and unique 4 Think through the complex pieces of the API 4 APIs can make thins simpler in the final view
This stuff is really hard 4 You'll mess up 4
You'll forget something 4 You'll build it weird 4 That's why we version things
Some other tips 4 SSL 4 Build stuff with your
API, that'll tell you how hard it is 4 Read other API docs and build with their API 4 Provide Libraries
Questions?