記事の概要

Laravelを使ったAPIの建て方を学べます。**質はともかく、**多分これが最速だと思います。（フラグ）

注意事項

あくまでフロントエンドエンジニアが趣味開発とかプライベートでちょっと触る場合にのみ使ってください。

記事の対象

フロントエンドがメインだけど、Webサービスを作る上ではバックエンドも避けて通れないのでちょっと触ってみたい。主流のRuby&RoRかPHP&Laravelを学習してみたいが、~~RoRはなんか終わりっぽいし（誹謗中傷）~~、Laravelにしとくか……という層をターゲットにしています。

先に知っておきたいLaravelぶっちゃけ話

開発方針について

フロントエンジニアの皆さんは、
昔はバックエンドからHTMLを出力するモノリスが主流だったけど、今はフロント（SPA）とバック（API）を分離して開発しやすくするのが主流
……という価値観を持っている方が多いかと思います。しかし残念ながら、
LaravelはバックエンドからHTMLを吐き出すモノリス路線（密結合路線）がメインです。
というのも、初版が2011年6月に作られたんですが、当時はフロント-バックの分離モデルが流行る前だったんですね。このためどうしても根底からコンセプトの切り替えはし辛く、メインはモノリスだけど、APIも作れるようにする……という温度感で現在も進化が続いています。「ここ数年、CakePHPの後継として流行ってるみたいだし、基本APIベースで作るの楽々やろ😁」と思ってたそこの貴方、残念ですが、半分当たり、半分外れといったところです。
正直、学習を進めていくうちにこの辺りの温度感が分かってきて、「先行き的にどうなんだ？」と若干躊躇した時もありました。どうしてもモノリスってPHPやRubyからWebpackラッパーライブラリを経由してWebpackを叩いてフロント周りのライブラリまでバックで丸抱え、みたいな「明らかに力技すぎるだろ」みたいな方向になってるようですし。ただまぁ御存知の通りシェアが大きいですし、次に何かが来てるというわけでもないので……。

設計について

最初からざっくりと設計とか仕組みが出来上がっていて、FWの中に設定や独自ロジックを追加して風船のように大きくしていくイメージになります。フロントとは全然違う感覚でかなり新鮮ですね。
ただそのままだとコントローラーがすぐに太ったりとかモデルが太ったりとか、すぐにあるあるBadパターンになるので、どう見通しよく細分化していくか、設計については常に意識することになると思います。
またフロントでは関数型に寄せたスタイルが流行しており、「クラスなんて太古の時代の遺物は使いませんなぁ～🤭（鼻ホジ）TS最高！🙌」というナウなイケイケヤング（死語）もいるかもしれませんが、Laravelは思い切りオブジェクト指向のため、合わせる必要があります。どちらにせよ良くも悪くも大枠を握られてるので、突っ張っても噛み合わせ悪く感じるというか。できる限り副作用あり関数と純粋関数をきっちり分けて書くとかぐらいですかね……。（Serviceクラスという名のstaticな純粋関数を詰め込んだクラス群を隠しながら）

学習のやり方

PHP自体やDB、あと環境構築で触ることになるだろうDockerについては触れません。
フロントエンジニア視点では、Laravelの機能のうちblade周りをバッサリ捨てて、APIを立てることに絞って学習する流れになるかと思います。
学習は公式サイト日本語訳で行うのが確実で手っ取り早いでしょう。この記事はこのサイトの見るべき項目を優先度順に並べる形をとります。同じ優先度の場合は上から順に見ていけば良いようにしてあります。
ちなみにココ、Laravelのコミュニティによる公式だと勘違いしてる人がちょくちょくいますが、一番下のコピーライト表示見る限り、Laravelに関する電子書籍等も出されている川瀬裕久氏によるボランティアです。感謝しながら読みましょう。

注意事項

どの項目も長いですが、明らかに関係ある項目は最初から最後まで飛ばさず全部読んでください。　抽象的だったりLaravelの仕組みを多少分かってないと理解できない書き方で、必要な作業がさらっと書かれてたりするので注意。
エラーが出て散々StackOverFlowやらLaracast等で検索して回った結果、実はマニュアルに記載されてて、「これ、さらっと書いてあるけど、そういう意味かよ～！（＝実作業として何をする必要があるのか分かってない）」と天を仰いだことが数回あります😔

重要度:★★★★★

とりあえずDBを設定→APIを立ててDBに読み書きできるようにします。

事前準備

必要なので読んでください。あと最初のうちは「あのクラスってどのディレクトリの中だっけ……」とディレクトリのツリーの中で迷子になること必至なので、構造についてもざっくり学んでおきましょう。

開発

DBのテーブル設定してAPI立てて、Eroquent経由で読み書きするという形になります。

運用

利用開始：デプロイ

重要度:★★★★

このままだとコントローラーに全処理を埋め込むことになるので、公式が提供するクラス分割の手段を学びます。
また自動テストの学習を後回しにしてTS＋SPAフレームワークの学習に集中してるフロントエンジニアもぶっちゃけ多いかと思いますが、バックエンドは自動テストの重要性が段違いのため、この段階で触れます。

設計

DBのデータの取り回し

自動テスト

重要度:★★★

おそらく「自動でなんかやってくれて動いてるけど、仕組みがよく分かってなくて地が足についてない」感が強いと思うので、ベースとなる仕組みを学びます。というか、ここまでの項目でもさらっと使われてたりするので、やってる内に気になってつまみ食い的に読むことになるかと。

番外：認証周りについて

バックエンドと言えば認証かと思いますが、残念なことにLaravelの認証周りのライブラリは乱立しています。 やたらJetstreamやBreezeを推してきますが、これは画面付きのため、フロントエンジニア的には選択肢に入らないかと思います。
結論からいうと、学習する必要があるのは3つです。

Laravel Sanctum

ブラウザ向けのCookieを使った認証と、他のサーバーサイドプログラム向けのAPIキー認証を両立しつつ、同じ「/login」の口で処理してくれるというライブラリになります。ログアウト等、2要素認証、パスワードリセット等は独自で実装する必要があります。
「なんだそれだけか」と思われるかもしれませんが、オープンなAPIのみを作るならともかく、実際のところ認証やそれを伴う管理画面、あるいは他のサーバーサイドプログラムとの連携はすぐに必要になってくるので、結局必須ライブラリになります。

Laravel Fortify

Sanctumと混同しがちですが、2要素認証やパスワードリセット等、認証周りのよくある機能を付け加えるライブラリとなります。ただしバックエンドからHTMLを出力する前提で設計されているため、自動で設定されるAPIがRESTじゃなくて動詞になっているなど、ここからAPI派からすると微妙にチグハグ感出てきます。

Laravel Socialite

ソーシャルログイン用ライブラリ。Fortifyと同じでバックエンドがHTMLを出力する前提で設計されているので、結構弄る必要があります。
ここらへんになると（画面出力しない場合だと）英語の記事すら減ってきますので、日本語のおすすめの記事を貼っておきます。

ライブラリに依存したくない／学習コストが重い場合、Laravelは自前による実装の段取りもある程度用意してくれています。このことを踏まえて、マニュアルの「安全」の各項目や、マニュアル内の各ライブラリの紹介ページを読んでください。それから「基礎：CSRF保護」も読んでおいた方がいいですね。

🙏Laravel公式ドキュメント翻訳者への支援のお願い

Laravelの公式ドキュメントの日本語版であるReaDouble.comを運営されている川瀬裕久氏が、広告収入の低下と持病の悪化のため、翻訳プロジェクトを継続することが困難になり、GitHub sponsorsを募集しています。日本のLaravelユーザーでここを見たことない人はいないと思うので、もし恩義を感じているならば是非支援のほどお願いします。私も支援させていただいております