Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
JSON API - standards please
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Michal Ostruszka
January 14, 2014
Programming
280
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
JSON API - standards please
Slides from my Meet.JS talk on JSON API standards (JSend and JSON API specifications)
Michal Ostruszka
January 14, 2014
More Decks by Michal Ostruszka
See All by Michal Ostruszka
Building modern web applications. Single Responsibility Principle applied
mostr
2
450
Building modern web applications. Single Responsibility Principle applied
mostr
4
170
You don't need Rails
mostr
3
190
Backendless frontend development
mostr
2
330
Code review, do you speak it?
mostr
0
610
Things you probably should know about JavaScript that you may not have been told before
mostr
6
730
Other Decks in Programming
See All in Programming
React Native経験者が Flutterを30⽇間触って驚いたこと
3saito
0
160
クラウドエージェントは、 何がそんなに便利なのか / what makes cloud agents so useful
rkaga
5
800
AI駆動開発4年目の現在地(『あなたはFDEになるべきか?』イベント資料)
kumaiu
0
310
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
4
3.5k
複数ドメインを一つのアプリに統合するFlutterの設計と運用_FlutterKaigi2026登壇資料(須永高弘)
takahirosunaga
0
160
느린 네트워크와 저사양 디바이스 사용자를 위한 웹뷰 로딩 시간 개선기
kmkim
1
210
AI時代のFlutter品質設計 — アプリ品質を守るQuality Layers
omatty198
0
360
Claude Code ハーネスDeep Dive – 君はどこまで制御する? -
takateeen_knj
0
450
作れる、でも消せるか?──安全に「枯らして消す」機能削除術 / Drain, Then Delete
chobishiba
3
1.4k
Long Living Tokens, Die, Die, Die! (or: The One Ring is Banned in Modern)
sylph01
0
410
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
540
そのデザイントークン、Flutterでも同じ見た目になりますか?
nakamizu
0
310
Featured
See All Featured
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
560
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
560
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
760
A Modern Web Designer's Workflow
chriscoyier
699
190k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
70
68k
Utilizing Notion as your number one productivity tool
mfonobong
4
640
Leo the Paperboy
mayatellez
10
2.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Limits of Empathy - UXLibs8
cassininazir
2
770
The SEO Collaboration Effect
kristinabergwall1
1
620
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
610
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