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
JSON API - standards please
Search
Michal Ostruszka
January 14, 2014
Programming
2
260
JSON API - standards please
Slides from my Meet.JS talk on JSON API standards (JSend and JSON API specifications)
Michal Ostruszka
January 14, 2014
Tweet
Share
More Decks by Michal Ostruszka
See All by Michal Ostruszka
Building modern web applications. Single Responsibility Principle applied
mostr
2
430
Building modern web applications. Single Responsibility Principle applied
mostr
4
160
You don't need Rails
mostr
3
180
Backendless frontend development
mostr
2
310
Code review, do you speak it?
mostr
0
500
Things you probably should know about JavaScript that you may not have been told before
mostr
6
680
Other Decks in Programming
See All in Programming
効率的な開発手段として VRTを活用する
ishkawa
0
140
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
170
XP, Testing and ninja testing
m_seki
3
250
Team operations that are not burdened by SRE
kazatohiei
1
310
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
420
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
560
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
110
A2A プロトコルを試してみる
azukiazusa1
2
1.4k
Goで作る、開発・CI環境
sin392
0
230
生成AI時代のコンポーネントライブラリの作り方
touyou
1
220
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.5k
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
820
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
How GitHub (no longer) Works
holman
314
140k
Typedesign – Prime Four
hannesfritz
42
2.7k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
Fireside Chat
paigeccino
37
3.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Transcript
JSON API standards please Michał Ostruszka | @mostruszka | michalostruszka.pl
every app defines own “standard” Wild, wild west
{ “status”: “ok”, “response”: {...} }
{ “result”: “success”, “data”: [] }
{ “status”: 200 }
{ “result”: “error”, “msg”: “No such user” }
{ “status”: 404, “error”: “No such user” }
{ “status”: 404, “errors”: [ “No such user” ] }
and so on...
sometimes even within one app Inconsistency
Any standards?
“JSend is a specification that lays down some rules for
how JSON responses from web servers should be formatted” JSend
JSend - success { “status”: “success”, “data”: { “posts”: [...]
} } required: status, data
JSend - failure { “status”: “fail”, “data”: { “title”: “Title
is required” } } Used for invalid data responses required: status = “fail”, data
JSend - error { “status”: “error”, “message”: “Server goes bananas”
} Used for server errors required: status = “error”, message optional: code, data
simple easy to follow, “data” can contain anything That’s all
only 41 various interpretations not always flexible enough Wait, HTTP
codes?
“If you've ever argued with your team about the way
your JSON responses should be formatted, JSON API is your anti-bikeshedding weapon.” JSON API
defines data format, mime type registered application/vnd.api+json relations etc Bigger
spec
ID style URL style Flavors
JSON API - Simple { “posts”: [{ “id”: 1, “title”:
“Hello world” }] } always as list, even for 1 item item MUST contain “id”
JSON API - Relationships { “posts”: [{ “id”: 1, “title”:
“Hello world”, “links”: { “author”: “9” “comments”: [“1”,”2”,”3”] } }] } Client needs to know how to build author url
Embedded in “linked” field Save HTTP requests Compound docs
Same for simple resources URL Style
URL Style { “posts”: [{ “id”: 1, “title”: “Hello world”,
“links”: { “author”: “http://example.com/author/2” } }] } client can blindly follow URLs
GET /posts/1?include=comments GET /posts/1?include=comments.author Selective fetching
Defines how to send data POST, PUT, DELETE etc Resources
manipulation
No status in response body HTTP codes used to determine
status Relies on HTTP codes
Once JSON API is stable, it will always be backwards
compatible using a never remove, only add strategy Changes?
http://labs.omniti.com/labs/jsend http://jsonapi.org/ Where to find?
Possible adoption? Stick to standard for your project JSend looks
easier Final word
kthxbye