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
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
600
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
TechTown - Creating Composable Callables in Contemporary C++
rollbear
0
130
Optunaを作ったときにやりたかったこと、その後 (2026/10/16, Optuna Meetup #3)
iwiwi
1
430
GemmaをJevのように使ってみる / Use Gemma like Jev
kishida
5
790
AI時代のコードレビューは人に向けるな、仕組みに向けろ
texmeijin
5
3.7k
JAWS-UG 東京支部が始める、JAWS-UG支部コラボ / JAWS-UG lunchtime LT Collaboration
y0hgi
0
270
sbt 2.0: takeoff
eed3si9n
0
160
ソニーのクラウド共通基盤の変遷とAI時代の開発スタイルに合わせた進化 / The Journey of Sony’s Common Cloud Platform and Its Evolution for AI-Native Development
kenjiyoneyama
0
270
AIに “答え“を書かせるのを やめてみた
___akari11
0
120
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
1.1k
UnityでSystem.Net.WebSocketsなWebSocketサーバが動かないのでUnity Monoのコードを覗いてみた / about implementing websocket server with unity mono
drumath2237
1
610
dotNET_vulnclicker_intro.pdf
deka_morita
0
140
Next.js: The final boss of Web Performance
guaca
0
250
Featured
See All Featured
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
4 Signs Your Business is Dying
shpigford
187
23k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3.1k
Agile that works and the tools we love
rasmusluckow
331
22k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
620
Skip the Path - Find Your Career Trail
mkilby
1
260
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
4
4.4k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
YesSQL, Process and Tooling at Scale
rocio
174
15k
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