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
つ・な・が・り・た・い REST_APIのお話
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
kirimaru
October 07, 2019
Programming
2.8k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
つ・な・が・り・た・い REST_APIのお話
kirimaru
October 07, 2019
More Decks by kirimaru
See All by kirimaru
早くAPI作るならFastAPI がオススメ
hirotokirimaru
1
140
DDD(ドメイン駆動設計)を知らない人に知ったつもりさせる/Introduce_DDD_to_unfamiliar_individuals
hirotokirimaru
0
410
例示! Spring Bootで作られた REST APIのテストコード/ Testing-Example-for-a-REST-API-created-with-Spring-Boot
hirotokirimaru
2
2.3k
一緒に使うことが多い値は別クラスにしよう(Data Clumps)/data_clumps_is_useful
hirotokirimaru
0
840
Backlogが好きな話。/i_like_backlog
hirotokirimaru
0
200
私が好きなポートアンドアダプターを紹介する/I-like-hexagonal-architecture.pdf
hirotokirimaru
1
1.5k
名付けのためにクラス図を元に会話しよう/Let's-use-class-diagram-to-communicate-with-client
hirotokirimaru
0
700
Code Smellsの Primitive Obsession に気を付けて設計する/Designing-with-Code-Smells-Primitive-Obsession
hirotokirimaru
1
4k
FCCを推す/My favorite software architecture is FCC
hirotokirimaru
0
310
Other Decks in Programming
See All in Programming
Ghostty + Neovimで作る 透明でカッコ良い開発環境
j341nono
0
160
複雑なUIコンポーネントとの ⻑い付き合い⽅:波及するバグからテスト戦略を経て、安全な再設計へ
mixplace
0
260
設計次第でAIコードの読む量は減らせる / designing-for-code-reading
minodriven
34
16k
技術的負債の返済は、AI時代の複利で効く投資 — 経営としての意思決定とその遂行
curekoshimizu
1
2.3k
Unity6 URPによる海底をテーマにしたVJシステムの解説 | Unity Shader 完全に理解した 勉強会
gam0022
0
340
残高管理から台帳サービスへの進化
artoy
0
180
速く作れる。その次は、速く確かめられる開発へ 〜AIネイティブ開発を支える、Shift Down〜 / Can build fast. Next, moving to development where we can verify fast.
rkaga
8
5.6k
半永久的に提供し続けられるプライベートクラウドを目指して ― 利用者の認知負荷を抑えるAPI抽象化とハードウェア世代交代の基盤設計
tomokon
0
470
SREの越境 / SRE Collaboration
y0hgi
2
300
iOS 27でニュースアプリはどう変わる!? 〜日経電子版の新機能対応と、開発事例から〜
lynnswap
7
13k
Herb in Rails 8.2: Your ERB views, now HTML-aware @ Rails World 2026, Austin, Texas
marcoroth
0
190
Workers Cache を知る
syumai
0
350
Featured
See All Featured
From π to Pie charts
rasagy
1
390
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
1.1k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
A better future with KSS
kneath
240
18k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
400
A Soul's Torment
seathinner
8
3.7k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
320
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.7k
Navigating Team Friction
lara
192
16k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.7k
Optimizing for Happiness
mojombo
378
71k
Transcript
つ・な・が・り・た・い REST APIのお話 タピオカLT 2杯目 きり丸(nainaistar) 1
自己紹介 水上皓登:きり丸 twitter: @nainaistar github: hirotoKirimaru 通信会社所属 2
昔抱いていたRESTの認識 3
昔抱いていたRESTの認識 ❏ Ajax通信をやるために、RESTって技術使えばいいらしい。 画面表示後にデータ取ってこれる! 画面操作しても再リロードが走らない! だから、UXが向上する! すごいぞ、REST! 4
昔抱いていたRESTの認識 ❏ これは本の管理画面で使うREST APIだから、 本の追加は ”http://domain/bookManage/insertBook”、 本の更新・削除は ”http://domain/bookMange/updateBook”、 本管理画面RestController.javaだ! 5
6
(ちゃんと学んだ) 今のRESTの認識 7
REST ≒ REST API RESTの原則に従ったAPIのこと ▰ APIが一般的にアクセス可能な状態で提供されている ▰ APIのURLはリソースの場所を表現している ▰
リソースに対して、HTTPメソッドで取得、更新等の操作ができる (リソースの操作方法が一般化されている) ▰ APIの処理結果はステータスコードで判断できる ▰ ステートレスで、リクエストごとに独立している 8
APIのURLはリソースの場所を 表現している 9
例) https://api.github.com/users/hirotoKirimaru/ https://api.github.com/users/hirotoKirimaru/repos ただし、検索に関してはsearchという文言が入ることがある https://api.github.com/search/code?q=readme+user:hirotoKirimaru (※) URLはリソースの場所を表現するので 名詞となるのが特徴 10
REST APIはリソース指向。 http://api.domain/books SOAP, gRPC等のRPCはサービス指向。 サービス名/メソッド名とかになる。 http://domain/bookManage/insertBook http://domain/bookManage/updateBook URLはリソースの場所を表現するので 名詞となるのが特徴
11
リソースに対して、 HTTPメソッドで取得、更新等の操作ができる (リソースの操作方法が一般化されている) 12
リソースに対して、HTTPメソッド で操作ができる 13 HTTP 機能 CRUD GET 取得 SELECT POST
更新(登録) UPDATE(INSERT) PUT 登録 INSERT DELETE 削除 DELETE PATCH 更新 UPDATE
❏ APIの処理結果は ステータスコードで判断できる ❏ APIが一般的にアクセス可能な状態で 提供されている 14
APIの処理結果は ステータスコード で判断できる 15 HTTP_STATUS 内容 100系 情報レスポンス 200系 成功
300系 リダイレクト 400系 クライアントエラー 500系 サーバエラー
SOAP(RPC)は? 16 SOAPの場合、多少のエラーがあっても、ステータスコードは200、 BODYにエラー内容を記載していることがある。 ステータスコードが200以外のパターンは、 リバースプロキシやApacheなどのシステムに繋がらない場合に返却することで、障害 を切り分けられるようにしている。 HTTPを隠蔽してJava等の言語レイヤーだけで 開発できるようにするという思想。(※Real world
Http 141p)
None
None
ステートレスで、 リクエストごとに独立している 19
ステートレスで、 リクエストごとに 独立している 20 GETメソッドは、常に同じ値を返却する。(リソース更新が入らない限り) PUTメソッドは、常に同じ値を登録し続ける。 トランザクションを提供できないので、 トランザクションが必要な単位でなるべく細かいAPIにすることが大事。
その他 21
REST APIに向いているサービス 22
REST APIに向いている サービス 23 ▰ HTTPメソッドで操作しきれないサービス ▰ 例) DropboxはRESTからRPCの提供に変更 ▰
複数のリソースに対してアクセスするAPI ▰ 例) ユーザの投稿、写真、ユーザの友達の写真等々の facebook, instagram等で試用されているGraphQL。
おわり 24
APPENDIX 25
26
参考ページ 27 ▰ https://www.w3.org/TR/soap/ soapは1.2が最新 ▰ Restはとくにない? ▰ https://github.com/graphql/graphql-js/releases graphQLはv14.5.8?
▰ https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md gRPCは1.24が最新_1.25のgは(game)
参考図書 28 Real world Http