Enviar búsqueda
Cargar
REST API のコツ
•
58 recomendaciones
•
52,463 vistas
pospome
Seguir
社内勉強会向け資料
Leer menos
Leer más
Tecnología
Denunciar
Compartir
Denunciar
Compartir
1 de 61
Descargar ahora
Descargar para leer sin conexión
Recomendados
脱RESTful API設計の提案
脱RESTful API設計の提案
樽八 仲川
Rest ful api設計入門
Rest ful api設計入門
Monstar Lab Inc.
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
クラウド環境下におけるAPIリトライ設計
クラウド環境下におけるAPIリトライ設計
Kouji YAMADA
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
shinjiigarashi
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
Recomendados
脱RESTful API設計の提案
脱RESTful API設計の提案
樽八 仲川
Rest ful api設計入門
Rest ful api設計入門
Monstar Lab Inc.
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
クラウド環境下におけるAPIリトライ設計
クラウド環境下におけるAPIリトライ設計
Kouji YAMADA
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
shinjiigarashi
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと
土岐 孝平
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
Yasuhiro Mawarimichi
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
Daichi Koike
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Serverless時代のJavaについて
Serverless時代のJavaについて
Amazon Web Services Japan
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
Yoshiki Nakagawa
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Shingo Fukui
backlogsでもCI/CDする夢を見る
backlogsでもCI/CDする夢を見る
Takeru Maehara
Web API: The Good Parts 落穂ひろい
Web API: The Good Parts 落穂ひろい
API Meetup
Go言語によるwebアプリの作り方
Go言語によるwebアプリの作り方
Yasutaka Kawamoto
Más contenido relacionado
La actualidad más candente
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと
土岐 孝平
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
Yasuhiro Mawarimichi
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
Daichi Koike
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Serverless時代のJavaについて
Serverless時代のJavaについて
Amazon Web Services Japan
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
Yoshiki Nakagawa
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Shingo Fukui
backlogsでもCI/CDする夢を見る
backlogsでもCI/CDする夢を見る
Takeru Maehara
La actualidad más candente
(20)
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
Serverless時代のJavaについて
Serverless時代のJavaについて
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
backlogsでもCI/CDする夢を見る
backlogsでもCI/CDする夢を見る
Destacado
Web API: The Good Parts 落穂ひろい
Web API: The Good Parts 落穂ひろい
API Meetup
Go言語によるwebアプリの作り方
Go言語によるwebアプリの作り方
Yasutaka Kawamoto
AWSのセキュリティについて
AWSのセキュリティについて
Yasuhiro Horiuchi
ZabbixによるAWS監視のコツ
ZabbixによるAWS監視のコツ
ShinsukeYokota
AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs
AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs
Amazon Web Services Japan
AWS Systems manager 入門
AWS Systems manager 入門
Serverworks Co.,Ltd.
CloudWatchの使い方
CloudWatchの使い方
ShinsukeYokota
AWS初心者向けWebinar AWSとのネットワーク接続入門
AWS初心者向けWebinar AWSとのネットワーク接続入門
Amazon Web Services Japan
Black Belt Online Seminar Amazon CloudWatch
Black Belt Online Seminar Amazon CloudWatch
Amazon Web Services Japan
AWS Black Belt Online Seminar 2017 Amazon S3
AWS Black Belt Online Seminar 2017 Amazon S3
Amazon Web Services Japan
AWS セキュリティとコンプライアンス
AWS セキュリティとコンプライアンス
Amazon Web Services Japan
AWS サービスアップデートまとめ re:Invent 2017 直前編
AWS サービスアップデートまとめ re:Invent 2017 直前編
Amazon Web Services Japan
AWS AI Solutions
AWS AI Solutions
Amazon Web Services Japan
Destacado
(13)
Web API: The Good Parts 落穂ひろい
Web API: The Good Parts 落穂ひろい
Go言語によるwebアプリの作り方
Go言語によるwebアプリの作り方
AWSのセキュリティについて
AWSのセキュリティについて
ZabbixによるAWS監視のコツ
ZabbixによるAWS監視のコツ
AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs
AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs
AWS Systems manager 入門
AWS Systems manager 入門
CloudWatchの使い方
CloudWatchの使い方
AWS初心者向けWebinar AWSとのネットワーク接続入門
AWS初心者向けWebinar AWSとのネットワーク接続入門
Black Belt Online Seminar Amazon CloudWatch
Black Belt Online Seminar Amazon CloudWatch
AWS Black Belt Online Seminar 2017 Amazon S3
AWS Black Belt Online Seminar 2017 Amazon S3
AWS セキュリティとコンプライアンス
AWS セキュリティとコンプライアンス
AWS サービスアップデートまとめ re:Invent 2017 直前編
AWS サービスアップデートまとめ re:Invent 2017 直前編
AWS AI Solutions
AWS AI Solutions
Similar a REST API のコツ
エンジニアのための勉強会 #3 『RESTful API』
エンジニアのための勉強会 #3 『RESTful API』
Naoki Yoshitake
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
Kazuya Sugimoto
Api設計
Api設計
Yuto Suzuki
APIとは
APIとは
moonfactory Inc.
APICのREST API入門
APICのREST API入門
Takehiro Yokoishi
Editor-based REST Client のご紹介
Editor-based REST Client のご紹介
知之 朝枝
RestfulなAPIの設計のお話
RestfulなAPIの設計のお話
ftsan
マッシュアップ勉強会
マッシュアップ勉強会
guestadcb01
マッシュアップ勉強会
マッシュアップ勉強会
seiryo
Spring'17リリースノート輪読会 API By フレクト
Spring'17リリースノート輪読会 API By フレクト
政雄 金森
RESTful API (JAX-RS) 書くだけで仕様書も自動で作られていく話 with MicroProfile Open API
RESTful API (JAX-RS) 書くだけで仕様書も自動で作られていく話 with MicroProfile Open API
Kohei Saito
Web api beginners
Web api beginners
Hirohide Sano
Adwords Api Developer Guide Summary
Adwords Api Developer Guide Summary
Toshiyuki Maeda
2015/11/15 Javaでwebアプリケーション入門
2015/11/15 Javaでwebアプリケーション入門
Asami Abe
Railsから学ぶRESTfulなuri設計
Railsから学ぶRESTfulなuri設計
Kanako Kobayashi
Heroku HTTP API Design Guide
Heroku HTTP API Design Guide
Ayumu Aizawa
Restful Web Service Ch2
Restful Web Service Ch2
kunit
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
DIVE INTO CODE Corp.
RESTfulとは
RESTfulとは
星影 月夜
BEAR.Sunday@phpcon2012
BEAR.Sunday@phpcon2012
Akihito Koriyama
Similar a REST API のコツ
(20)
エンジニアのための勉強会 #3 『RESTful API』
エンジニアのための勉強会 #3 『RESTful API』
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
Api設計
Api設計
APIとは
APIとは
APICのREST API入門
APICのREST API入門
Editor-based REST Client のご紹介
Editor-based REST Client のご紹介
RestfulなAPIの設計のお話
RestfulなAPIの設計のお話
マッシュアップ勉強会
マッシュアップ勉強会
マッシュアップ勉強会
マッシュアップ勉強会
Spring'17リリースノート輪読会 API By フレクト
Spring'17リリースノート輪読会 API By フレクト
RESTful API (JAX-RS) 書くだけで仕様書も自動で作られていく話 with MicroProfile Open API
RESTful API (JAX-RS) 書くだけで仕様書も自動で作られていく話 with MicroProfile Open API
Web api beginners
Web api beginners
Adwords Api Developer Guide Summary
Adwords Api Developer Guide Summary
2015/11/15 Javaでwebアプリケーション入門
2015/11/15 Javaでwebアプリケーション入門
Railsから学ぶRESTfulなuri設計
Railsから学ぶRESTfulなuri設計
Heroku HTTP API Design Guide
Heroku HTTP API Design Guide
Restful Web Service Ch2
Restful Web Service Ch2
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
RESTfulとは
RESTfulとは
BEAR.Sunday@phpcon2012
BEAR.Sunday@phpcon2012
Más de pospome
トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
pospome
MicroServices & APIs
MicroServices & APIs
pospome
どこに何を書くのか?
どこに何を書くのか?
pospome
アプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考える
pospome
Datastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについて
pospome
Goのシンプルさについて
Goのシンプルさについて
pospome
パッケージの循環参照
パッケージの循環参照
pospome
Controllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについて
pospome
サーバサイドNodeの使い道
サーバサイドNodeの使い道
pospome
Más de pospome
(9)
トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
MicroServices & APIs
MicroServices & APIs
どこに何を書くのか?
どこに何を書くのか?
アプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考える
Datastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについて
Goのシンプルさについて
Goのシンプルさについて
パッケージの循環参照
パッケージの循環参照
Controllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについて
サーバサイドNodeの使い道
サーバサイドNodeの使い道
Último
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
Último
(8)
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
REST API のコツ
1.
REST API のコツ
2.
自己紹介 名前 : pospome ブログ
: http://d.hatena.ne.jp/pospome/ 職種 : サーバサイドエンジニア
3.
これは REST API
の基礎部分は理解した上で 実装前に見るといいかもしれない資料です
4.
なぜ勉強しようと思ったのか?
5.
半年ほど某有名APIを触る機会があった そのAPIは(当然ながら)設計に一貫性があり 自分の作る変なAPIとは大違いだった
6.
RESTって URI と HTTPメソッドだけ決めれば いーんじゃないの? このままじゃダメな気がする 自分は
REST API を設計できないことを知った
7.
ということで、コツを紹介していきます
8.
LSUDs / SSKDs
9.
Web API には大きく分けて2種類ある それが
LSUDs と SSKDs どちらを作るのかでAPIの性質が変わる
10.
LSUDsとは ・Large Set of
Unknown Developers ・不特定多数のユーザーに提供するAPI 例:FaceBookAPI, TwitterAPI ・ユーザーの要求に最適化したAPIを 実装することは不可能なので、 データの種類別にエンドポイントを定義する傾向にある
11.
LSUDsとは ・最適化は不可能だが、 最低限の要求には応えられるように 細かいオプションを用意したAPIになっていたり、 APIの数が多い 例:フィールド指定、ソート指定 ・APIへのアクセス数を減らし、利便性を上げるために 関連するデータを一緒に返すことも考える 最適化できないながらも ユーザーのユースケースに寄せた設計にする
12.
SSKDsとは ・Small Set of
Known Developers ・特定のシステムのみで利用する専用のAPI 例:自社サービス、社内システム ・用途が決まっているので、 データの種類よりも画面別、アクション別に エンドポイントを定義する傾向にある 一般的にAPIというと LSUDs のイメージが強いので、 DBを抽象化したAPIを作りたがる人もいるが、 リソース指向のリソースはDBのテーブル単位とは限らない リソースとは利用者の要求を満たすデータ 1画面の表示に必要なデータの集合体もリソースになる
13.
SSKDsとは ・1画面1API , 1アクション1API
が基本 ボトルネックになる通信回数を最小限にする クライアント側が管理するAPIを最小限にする ただし、無理に1画面1APIにする必要はない サービスの仕様に合ったAPIを実装するのが大事 ・必要な情報が決まっているので、 取得データの細かいオプション指定は不要だが、 クライアントの必要とするデータを 最適化して返す必要がある
14.
LSUDs を SSKDs
に変換する APIサーバを用意するアーキテクチャもある LSUDs API APIサーバ SSKDs API ブラウザ IOS Android
15.
DBのデータ構造をそのまま返すAPIはNG クライアントのために DBを抽象化しなければならない クライアントが使いやすいAPIを心がけよう サーバサイドの基本は受け身 どちらを選択してエンドポイントを 設計するかが最初の1歩になる
16.
SSKDs は自分たち専用であり、 LSUDs を参考にできない部分があるので、 オレオレ仕様になりがち 「チームで共通の認識を持てればいい」 「ドキュメントあるからそれを見ればいい」 ↑ こういう会話が出てくると危ない 正しい設計を見失ってる兆候
17.
変な設計にしてしまうと ドキュメント更新が止まった時に困ったり・・・ 毎回口頭で説明することになったり・・ 色々と面倒です 事前にちゃんと設計しておくことが大事
18.
URI設計
19.
・リソースは集合体なので基本的に複数形にする 1つのデータだから単数形、 複数のデータだから複数形ということではなく、 リソースとしての表現を統一する NG test.com/user/100 ←取得するデータは1件 NG test.com/users/
←取得するデータは複数件 OK test.com/users/100 OK test.com/users/ 扱うリソースが単数に限られる場合は単数にしてもいい
20.
・リソースは可能な限りパスで表現する NG test.com/users/ ←一覧を返す NG test.com/users/100 ←指定されたidで返す OK
test.com/users/list OK test.com/users/(detail)/100 単語を繋げる場合はパスとして表現できないかを検討する NG test.com/latest_users_list OK test.com/users/list/latest
21.
・HTTPメソッドで表現できるのであれば、動詞は含めない NG POST test.com/users/add OK
POST test.com/users/ GETなど明示的に動詞を含めることで 表現に幅を持たせる事ができるケースもあるので、 動詞を使ってはいけないということではない GET test.com/users/search?name=suzuki&age=20
22.
・オプションはパスではなくクエリパラメータにする NG test.com/users/3 OK test.com/users?page=3 ・Viewがある場合はAPIであることを明示する ViewなのかAPIなのかを明示しないと管理しにくい NG
test.com/users/100 OK test.com/api/users/100 OK api.test.com/users/100
23.
・自分の情報であればid指定ではなく、 self, me というエイリアスを利用できるようにする NG
test.com/users/100 OK test.com/users/me エイリアスは便利なだけではなく、 Controllerのエントリーポイントを分けられる 権限周りのバリデーションを分けるたり、 me なのにバリデーションがかかっていないなどの 不具合もパッと見で確認できる エイリアスを利用するには サーバ側でidを特定できる必要がある
24.
個人的な実装になってしまいますが、 SSKDs の場合には以下の様なURIにすることが多いです 【HTMLを表示するためのURI】 GET test.com/users/ 【画面表示用API】 GET
test.com/api/v1/view/movie_list GET test.com/api/v1/view/movie_detail/{id} GET test.com/api/v1/view/common/header 【Action用API】 POST test.com/api/v1/action/movie/ PUT test.com/api/v1/action/movie/{id} DELETE test.com/api/v1/action/movie/{id}
25.
有名どころのAPIでも違いがあったりするので、 どれかに寄せて作ると一貫性があって、 きれいなAPIになる URI設計については このスライドの説明を真に受けてはいけない 一貫性が大事
26.
APIバージョン
27.
APIにバージョンを持たせることで クライアント側で利用するAPIを任意に選択できる サーバのAPI変更作業にクライアントが引っ張られない バージョンアップのタイミングでリファクタリングが可能 後方互換を保とう test.com/v1/users/list test.com/v2/users/list URIではなく、 HTTPヘッダーに指定されたバージョンを元に ルーティングする方法もある
28.
HATEOS
29.
HATEOS Hypermedia As The
Engine Of Application State リソース同士に関連性のあるAPIのこと
30.
(´・ω・`) ?
31.
以下はAPIのレスポンスです 一応JSONっぽく書いてます { users:{ { id:1, name:'sato' }, { id:2, name:'suzuki' }, } }
32.
HATEOSにしました { users:{ { id:1, name:'sato', link: { href: “http://api.test.com/users/1” } }, { id:2, name:'suzuki', ink:
{ href: “http://api.test.com/users/2” } }, } }
33.
HATEOSは レスポンスの中に次の動作に必要なAPIを用意する形式 HTMLのようなリンクのあるデータ構造になるので、 クライアント側でAPIの管理をしなくていい JSON に <a>
を埋め込むイメージ *先ほどのHATEOSの例は簡易的なものです 本当はもっとフィールドが必要です
34.
【HATEOSのメリット】 ・APIのURI変更がサーバサイドで完結する ・クライアントがAPIを管理しなくていい 【HATEOSのデメリット】 ・採用事例があまりない気がする ・送信するデータ量が多くなる ・サーバサイドがデータの関連性を意識する必要がある SSKDsだと画面遷移を意識する必要もあるので、 画面側の仕様変更が実装に影響しやすくなる
35.
APIのレスポンスデータ構造
36.
すでに規格が存在する ・JSON-RPC ・HAL ・JSON API ・Collection+JSON これらを検討してもいいし、 自分で定義してもいい とりあえず、ググるといいかも
37.
レスポンスデータのコツ ・DBから取得したデータはクライアント用に加工して返す クライアントにとって最適なレスポンスを提供する ・DBのカラム名とレスポンスのフィールド名は 同じである必要はない クライアント側にとって自然なフィールド名にする
38.
・無駄な階層化を避ける { id:10, name: { last: “lastname”, first:
“firstname” } age: 20 } ↓ { id:10, last_name: “lastname”, first_name: “firstname”, age: 20 }
39.
・似たようなデータ構造は階層にしてもいい { my_last_name: “lastname”, my_first_name: “firstname”, friend_last_name:
“lastname”, friend_first_name: “firstname”, } ↓ { me: { last_name: “lastname”, first_name: “firstname”, }, friend:{ last_name: “lastname”, first_name: “firstname”, } }
40.
・レスポンスのトップレベルにオブジェクト名を付ける 何のデータであるかが分かりやすい [ {id:10, score:10}, {id:11, score:11}, {id:12,
score:12}, ] ↓ { users:[ {id:10, score:10}, {id:11, score:11}, {id:12, score:12}, ] }
41.
サーバ側がレスポンスを利用することはないので クライアントの要望に沿った構造にするのが基本
42.
APIのリクエストデータ構造
43.
リクエストについては レスポンス構造ほど考える必要はないので、 そんなに悩むこともないはず どのようなデータを渡すかくらいだと思う
44.
POST/PUT で利用する content-type だけ抑えておこう application/x-www-form-urlencoded or application/json
45.
application/x-www-form-urlencoded ・HTMLのForm送信 ・一般的なイメージはこれかも ・body部分に key=value&key=value の形式で データを格納する ・FWだと get_param(“key”)
とかで取得できる
46.
application/json ・個人的に Web API
の POST/PUT といえばこれ ・最近はSPAが主流だから 基本こっちを利用すると思うけど、 意外と知らない人が多い印象? ・body部分にJSON形式でデータを格納する ・FWだと get_body().parseJson() とかで パースしてから取得する必要があるかも get_param() 的なやつでは取れない印象
47.
application/json ・Form形式とは違い、 データをネストさせることができるので、 柔軟なデータ表現が可能になる 複雑なデータ構造を扱うならこれがいい ・レスポンスデータと同じように JSON Schema で管理できる ・レスポンスがJSONならリクエストもJSONなのでは? という自然な発想
48.
application/json の方が便利そうだけど、 HTMLのFormを利用するのであれば、 x-www-form-urlencoded の方がいいかもしれない Google,
FaceBook, Twitter も 統一されているわけではない
49.
エラー時のレスポンス
50.
大体以下が必要になる ・システムのエラーコード お問い合わせ対策&クライアント側のメッセージ出し分け 変に細かくすると管理が大変 ざっくりし過ぎると意味が無い ・開発者用のエラーメッセージ 本番環境では出力しないでおくといい ・エラーに対するドキュメントのリンク 普通に面倒なので SSKDs では不要だと思う
51.
・ユーザー用のエラーメッセージ ある程度抽象的なデフォルトメッセージは サーバで管理し、 必要に応じてクライアント側で上書きするのが望ましい
52.
サーバ側では 「システムエラーです」 「データが存在しません」 的な抽象的なメッセージとエラーコードを返す クライアント側では エラーコードと表示している画面によって、 「データが存在しません」を 「フレンドが存在しません。一度画面を更新してからもう一度操 作してください」 のようなユーザーに優しいものに書き換える エラーコードって結構強力
53.
メンテナンス用のレスポンス
54.
メンテ用のエラーレスポンスを作っておくと便利 ・メンテ用のエラーコード 503でもいいけどエラーコードが必要な場合は 用意しておく ・メンテ文言 ・メンテ開始、終了時間 ・ただ、なくてもなんとかなるので、どーでもいいかも
55.
HTTP Header
56.
HTTP Header の設定には便利なものが多い 普段は見ないところにも気を配ろう ・Expire ・Etag,
Last-Modified ・Cache-Control ・Content-Type ・Accept ・Content-Security-Policy ・X-Frame-Options ・X-XSS-Protection アプリケーショントークンのような固定値は Headerに設定できるようにすると APIの利便性が向上することもある HTTPの URI, Body だけではなく、Header も上手く使おう
57.
メジャーなAPIで学ぶ
58.
自分たちで考えても良いAPIはできない 本を読むことも大切だが、 世の中のAPIがどうなっているのかを知ろう 僕も時間をかけました ただし、 LSUDs と SSKDs
では設計方針が違うので、 そのまま流用できるわけではない APIは甘くない 事前に設計方針をすり合わせましょう
59.
まとめ
60.
REST API について 過去の僕のように HTTP
Method を使って、URIを決めるだけ と思ってませんか? REST API は奥が深い REST API に限らず新しい技術は危険がいっぱい 手に馴染むまでしっかり勉強しましょう
61.
おわり
Descargar ahora