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
フレームワーク バックエンド / 2023 ニフティ新人研修
Search
ニフティ株式会社
PRO
December 14, 2023
Programming
0
360
フレームワーク バックエンド / 2023 ニフティ新人研修
2023年度ニフティエンジニア新人研修の講義資料です。
ニフティ株式会社
PRO
December 14, 2023
Tweet
Share
More Decks by ニフティ株式会社
See All by ニフティ株式会社
GitHubで育つ コラボレーション文化 : ニフティでのインナーソース挑戦事例 - 2024-12-16 GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
2.3k
Grow on GitHub Collaboration Culture: Case Study of InnerSource Challenge - GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
31
これが俺の”自分戦略” プロセスを楽しんでいこう! - Developers CAREER Boost 2024
niftycorp
PRO
0
260
継続的な改善のためのmodulesの適切な分割単位 - NIFTY Tech Talk #23
niftycorp
PRO
0
130
Re:ゼロから始めるTerraform生活 ~IaC入門編~ - NIFTY Tech Talk #23
niftycorp
PRO
0
130
Terraformにベストプラクティスを取り入れた - NIFTY Tech Talk #23
niftycorp
PRO
0
160
AWS AppSyncを用いた GraphQL APIの開発について - NIFTY Tech Talk #22
niftycorp
PRO
0
230
「天気予報があなたに届けられるまで」 - NIFTY Tech Talk #22
niftycorp
PRO
0
220
@nifty天気予報:フルリニューアルの挑戦 - NIFTY Tech Talk #22
niftycorp
PRO
0
520
Other Decks in Programming
See All in Programming
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
2
170
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
110
Rails アプリ地図考 Flush Cut
makicamel
1
120
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
260
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1k
sappoRo.R #12 初心者セッション
kosugitti
0
250
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
9
1.8k
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
pylint custom ruleで始めるレビュー自動化
shogoujiie
0
120
チームリードになって変わったこと
isaka1022
0
200
Grafana Cloudとソラカメ
devoc
0
170
Djangoアプリケーション 運用のリアル 〜問題発生から可視化、最適化への道〜 #pyconshizu
kashewnuts
1
250
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
137
6.8k
Making Projects Easy
brettharned
116
6k
Git: the NoSQL Database
bkeepers
PRO
427
64k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Why Our Code Smells
bkeepers
PRO
336
57k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Side Projects
sachag
452
42k
Practical Orchestrator
shlominoach
186
10k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
410
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Transcript
2023年度エンジニア定例 フレームワーク回バックエンド
バックエンドパートでは 主にAPIについてお話しま す
話す内容 ・APIとは? ・APIの種類 ・REST APIとREST原則 ・リクエストとレスポンス ・HTTPメソッド ・ヘッダー ・URI ・ペイロード
・HTTPステータスコード
APIってなに?
沢山の言葉が出てきます アプリケーションプログラミングインタフェース(API、英: Application Programming Interface)[注釈 1]とは、広義では ソフトウェアコンポーネント同士が互いに情報をやりとりするのに使用するインタフェースの仕様である。 APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIX のような国際標準規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語の標準ライブラ
リ(例えば、C++のStandard Template LibraryやJava API(英語版)など)がある。 商業的に使われる狭義では、各種システムやサービス(ハードウェア、OS、ミドルウェアおよびWebサービス等)を利用す るアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である[1][2][3][4][5]。こちらの意味では、システムやサービスから直接提供されないもの、例えば言語の標準ラ イブラリは含まない。 APIはアプリケーションバイナリインタフェース (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフ ェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである[6](LSBはいろいろな規定の集合なの で、正確には「LSBには、ABIにまで踏み込んでいる部分もある」)。 引用: https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83% A7%E3%83%B3%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82% A4%E3%83%B3%E3%82%BF%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9
むずかしい
沢山の言葉が出てきます APIってわかりやすく 言うと何?
ソフトウェアの一部機能を公開/共有 出来る仕組みのこと 引用:https://www.itmanage.co.jp/column/application-programming-interface/
APIを使うと何がうれし い?
最新情報の取得が容易になる ⇒情報の確認や更新の手間が省ける 開発の効率化に繋がる ⇒機能の開発時間を大幅に短縮できる
APIにはどんな種類があ る?
主に2種類 WebAPI(今回説明するのはこちら) ⇒Webサービス機能の一部として提供されているAPI OSが提供するAPI ⇒OS上でプログラミングを行うために用意されたAPI 引⽤︓https://cloudapi.kddi-web.com/magazine/api-types-and-protocols
今回はWebAPIについて 説明
多くのWebAPIはREST原則に基づいている REST原則に基づいたものをREST APIと呼ぶ
REST原則って何?
原則1︓ステートレスなクライアント/サーバプロトコル HTTPメッセージの全てがリクエストを理解するための必要な情報を含んでいることから、HTTP通信を⾏うクライアントもサ ーバもメッセージ間におけるセッションの状態を記憶している必要がありません。 ※ ステートレスと表現していますが、実 際には Cookie などを使⽤しセッション状態を管理しています。 原則2︓リソースを⼀意なURIにより識別される RESTfulなシステムでは全てのリソース(情報)はURI(Uniform
Resource Identifier)で表現される ユニークなアドレスを持ちます。 原則3︓HTTPメソッドで操作⽅法を表現した統⼀されたインターフェース リソースを操作するメソッドは、HTTPで定義され ている "GET"、"POST"、"PUT"、"DELETE" などを使⽤します。つまり、情報を操作する命令体系があらかじめ定義されて います。 原則4︓アプリケーション情報と状態遷移の両⽅を扱える ハイパーメディアの使⽤リソースを様々な形式(HTML、XML、 JSON、バイナリ)で表現できるようにします。また、関連する データはハイパーメディア(リンク)としてデータに含め ることができます。 引⽤元︓https://www.infraexpert.com/study/sdn09.html
ちょっとむずかしい
簡単にすると... 原則1︓サーバーとクライアントがデータ交換をする時に、お互いのセッション状態は記憶してなくてもいいよ 原則2︓所望のデータを取りたい際に、APIを叩くときのおまじないは⼀意に定まるよ 原則3︓APIを叩く際には "GET"、"POST"、"PUT"、"DELETE" を使ってユーザが何をしたいのかをわかりやすくするよ 原則4︓アプリケーション情報と状態遷移の両⽅を扱える ハイパーメディアの使⽤リソースを様々な形式(HTML、XML、 JSON、バイナリ)で表現できるようにします。また、関連する データはハイパーメディア(リンク)としてデータに含め
ることができます
APIの実例を⾒てみる 実例として、zipcloudの郵便番号API検索を利⽤︓https://zipcloud.ibsnet.co.jp/doc/api
郵便番号検索のAPI $ curl “https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060” { "message": null, "results": [ {
"address1": "⾼知県", "address2": "南国市", "address3": "蛍が丘", "kana1": "コウチケン", "kana2": "ナンコクシ", "kana3": "ホタルガオカ", "prefcode": "39", "zipcode": "7830060" } ], "status": 200 }
何が起きているの︖
APIの概念について例⽰
ファストフードの注⽂に例えると
②商品 ①注⽂ お客 店員 ⾏動︓購⼊ 注⽂︓ハンバーガーセット ⾷べる場所︓店内
所定の注⽂をすると、 きちんと商品が貰える
APIも同じ
所定の注⽂(リクエスト)をすると、 きちんと商品(レスポンス)が貰える
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
HTTPステータスコード︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報)
知らない⾔葉が沢⼭ある
ひとつひとつ⾒ていく
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
HTTPレスポンス︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 HTTPレスポンス︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 HTTPステータスコード︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報)
メソッド(HTTPメソッド) とは︖
リクエストを⾏う際に 「どのような操作を⾏いたいか」 を決定するために使⽤します
主に4つのメソッドが使われている HTTPメソッド 機能 GET リクエスト先の情報(リソース)を取得する際 に使⽤する POST 新しいリソース情報を送り込む PUT リソース情報を新しい情報で置き換える
DELETE リソース情報を削除する
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) HTTPステータスコード︓200
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) HTTPステータスコード︓200
ヘッダーとは︖
クライアントやサーバーが HTTPリクエストやレスポンスで 追加情報を渡すことができる
代表的なヘッダー情報 ・サーバーとやりとりするための認証情報 ・やりとりした⽇時 ・クッキー ・などなど...
郵便番号検索のAPIのレスポンスヘッダ $ curl --head "https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060" HTTP/2 200 access-control-allow-origin: * content-type:
text/plain;charset=utf-8 x-cloud-trace-context: c948f2b622f8591dae93a05b17ce65c2 content-length: 290 date: Fri, 14 Jul 2023 04:41:35 GMT server: Google Frontend
URIとは︖
名前または場所を識別する書き⽅のルールの総称 (URN U URL) = URI
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) HTTPステータスコード︓200
ペイロードとは︖
パケット通信においてパケットに含まれるヘッダやト レーラなどの付加的情報を除いた、データ本体のこと
<リクエスト> POSTやPUTなどのHTTPメソッドを使う場合、 ここに各種情報を⼊れて叩く <レスポンス> 欲しいデータがこの中に⼊っているよ
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
HTTPレスポンス︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 HTTPレスポンス︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 HTTPステータスコード︓ 200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報)
HTTPステータスコードとは︖
レスポンスに表⽰される3桁の番号のこと クライアントのWebブラウザとサーバ間ではHTTPリクエストに対し てレスポンスを返す
ステータスコード 状態 説明 有名なステータスコード 100番台 正常 クライアントからのリクエスト を受け⼊れ可能で、継続して処 理されている状態 100
Continue リクエスト継続可能 200番台 正常 クライアントからリクエストが サーバに送られ理解されて受理 された状態です。 200 OK リクエストが正常に処理できた 300番台 正常 リクエストを完了させるために 追加的な処理が必要です。 300 Multiple Choice リクエストに対して 複数のレスポンスがあることを示す 400番台 エラー クライアント(ユーザ)側で操 作や⼊⼒に不備があった際に出 てしまうエラー 404 Not Found Webページが見つからない 500番台 エラー サーバ側で問題が⽣じていてい る際に出てしまうエラー 500 Internal Server Error 何らかのサーバ 内で起きたエラー
レスポンス リクエスト エンドポイント 通信元 URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 メソッド︓GET
HTTPレスポンス︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 HTTPレスポンス︓200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報) URI プロトコル︓https ドメイン︓zipcloud.ibsnet.co.jp リソースパス︓api/search パラメータ︓zipcode=7830060 HTTPステータスコード︓ 200 ヘッダー︓受付⽇時、コンテンツタイプなど ヘッダー︓通信元の情報など ペイロード︓住所や読み⽅など (ペイロード︓詳細な情報)
パラメータとは
APIが処理に使うための情報 主に3種類 パスパラメータ ⇒URLドメイン以下のパス 例)https://support.nifty.com/mypage/ クエリパラメータ ⇒URLの”?”以降 例)https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060 ペイロード ⇒HTTPリクエストの際に送るデータ本体
パラメータとは
もう⼀度APIの実例を⾒てみる
郵便番号検索のAPI $ curl https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060 { "message": null, "results": [ {
"address1": "⾼知県", "address2": "南国市", "address3": "蛍が丘", "kana1": "コウチケン", "kana2": "ナンコクシ", "kana3": "ホタルガオカ", "prefcode": "39", "zipcode": "7830060" } ], "status": 200 }
郵便番号検索のAPI $ curl https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060 { "message": null, "results": [ {
"address1": "⾼知県", "address2": "南国市", "address3": "蛍が丘", "kana1": "コウチケン", "kana2": "ナンコクシ", "kana3": "ホタルガオカ", "prefcode": "39", "zipcode": "7830060" } ], "status": 200 } URI ペイロード HTTPステータスコード レスポンス クエリパラメータ パスパラメータ