REST APIについて

はじめに

今回はREST API(WebAPI)について学習を行ったのでまとめたいと思います。

WebAPIとは

そもそもWebAPIとは何なのかを知らなかったので超簡単に説明します。
Webサービスで提供している機能やデータを別のプログラムから利用できるようにするための規約またはその実装を指します。
公開されているWebAPIを使用することによりサービスを全て実装する必要が無くなるため開発のコストや時間を削減することができます。

身近なWebAPIには以下のようなものが挙げられます。

何らかの施設や飲食店のホームページなどにGoogle Mapが組み込まれているのはGoogle Map APIで実現されています。

REST APIとは

REST(REpresentational State Transfer )の略で日本語に訳すと「分散型システムにおける設計原則群」となります。
すなわちAPIの設計ルールを意味しています。
RESTには以下6つの原則があり原則を満たした状態を「RESTful」と呼びます。

  1. クライアント/サーバー  
    クライアント/サーバーアーキテクチャで構成されていること。  
    クライアント側がサーバー側にリクエストを送りサーバー側はクライアント側にレスポンスを返す構成のことを指します。
  2. ステートレス  
    各単独のリクエストで情報が成り立っている状態のことを指します。

    • サーバセッションは使用しない。
    • 状態はリクエストに全て含める。
  3. キャッシュ制御  
    レスポンスは明示的または暗黙的にキャッシュ可能であることを指します。  
    不必要なクライアント/サーバー間の通信を排除することでユーザー体験の向上、リソース効率の向上が見込めます。

  4. 統一インターフェイス  
    4つの制約で成り立っています。

    • リソースの識別
       URIを使用することによりサーバーに保存されたデータを識別する。
    • 表現を用いたリソース操作
       クライアントからサーバーにリクエストを送る際に認証状などの追加情報を付与する。
    • 自己記述メッセージ
       クライアント/サーバー間のメッセージの内容がヘッダーに記述されている。
    • アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)
       レスポンスに現在の状態を踏まえて関連するハイパーリンクが含まれている。
  5. 階層化システム  
    特定の機能や役割を持ったサーバー(コンポーネント)が相互作用するアーキテクチャを指します。  
    多層アーキテクチャ構成にすることによって高い拡張性と再利用ができるメリットがあります。

  6. コードオンデマンド  
    プログラムコードをダウンロードしてクライアント側で実行することを指します。

    • メリット
      リリース済みのクライアントに対して機能追加ができる。
      サーバーの負荷が下がる。
    • デメリット
      複数ブラウザなどのクライアント環境の想定を行う必要があり評価が複雑になる。

URIの設計

以下の原則について考慮しながらURIの設計を行う必要があります。
- 短く入力しやすい(冗長なパスを含まない)  
× GET http://api.example.com/service/api/serch  
apiが重複&意味のないserviceという単語が含まれています。  
GET http://api.example.com/serch

  • できるだけ省略しない(人間が読んで理解できる)  
    × GET http://api.example.com/sv/u  
    sv、uが何を指しているのか理解できません。  
    GET http://api.example.com/users

  • すべて小文字であること(大文字小文字が混在していない)

  • 単語はハイフンでつなげること  
    アンダースコアは下線を引くためのものでハイフンは単語を繋げるためのものです。  
    そもそも単語を連結するくらいならURIを見直す必要があります。

  • 単語は複数形を利用すること  
    URIで表現しているのは「リソースの集合」であるため複数形で表現します。

  • エンコードを必要とする文字を使わない  
    URIから意味が理解できる必要があります。

  • サーバー側のアーキテクチャを反映しない  
    × GET http://api.example.com/cgi-bin/get_user.php?id=12345  
    サーバーサイドでphpが動いていることが予想でき悪意あるユーザーに脆弱性を突かれる危険があります。  
    サーバーサイドのアーキテクチャは反映せず純粋で綺麗なURIとして設計する必要があります。  
    GET http://api.example.com/users/12345

  • 改造しやすい(Hackable)  
    システム依存の設計では人が意味を理解できません。  
    × GET http://api.example.com/items/alpha/12345  
    × GET http://api.example.com/items/beta/23456  
    alpha、betaなどの意味の分からない単語は含めないようにしなければなりません。  
    たとえ裏側の動きがalphaサーバー、betaサーバーと別れていたとしてもAPI設計としては取り除くのが適切です。  
    GET http://api.example.com/items/12345

  • ルールが統一されていること  
    一定のルールに従って設計することで間違いを防ぐことができます。  
    × 友達情報取得  
    GET http://api.example.com/friends?id=12345  
    メッセージ投稿  
    GET http://api.example.com/friends/12345/message  
    友達情報を取得するAPIとしてクエリパラメーターを使用しているのに対してメッセージ投稿はパスパラメータとなっており統一されていません。  
    ○ 友達情報取得  
    GET http://api.example.com/friends/12345  
    メッセージ投稿  
    GET http://api.example.com/friends/12345/message

movieをリソースとしたURIの設計例

上述したURI設計の原則に則ってmovieをリソースとしてURIとHTTPメソッドを定義すると以下のようになります。 | URI | HTTP method | 動作内容 | | :----: | :----: | :----: | | /api/v1/movies | POST | movieデータの作成 | | /api/v1/movies | GET | movieデータの一覧を取得 | | /api/v1/movies/:id | GET | idで指定したmovieデータを取得 | | /api/v1/movies/:id | PUT | idで指定したmovieデータを更新 | | /api/v1/movies/:id | DELETE | idで指定したmovieデータを削除 |

おわりに

以上REST API(WebAPI)についてのまとめでした。 ご閲覧いただきありがとうございました。

Udemy - REST WebAPI サービス設計
Web APIとは?初心者にもわかる基本的な仕組みと活用方法

達人に学ぶDB設計を読んだ感想

はじめに

今回は達人に学ぶDB設計を読了したので感想をまとめたいと思います。

良かった点

  • トレードオフの原則で話が進められていること

    望ましいDB設計を行うために犠牲になっていることは何かが紹介されています。
    メリットとデメリットの両方を理解することは何事においても大切なことだと思います。

    学びになった点

  • 物理設計でテーブル定義・インデックス定義以降の流れ

    ハードウェアのサイジングやストレージの冗長構成決定なども物理設計の作業範囲に含まれていることを知りました。
    DBのデータを失うことは許されないためDBの耐障害性とバックアップについても学習することが不可欠であると認識できました。

  • バッドノウハウ・グレーノウハウについて

    本業で触っているシステムのDB設計が一部バッドノウハウ・グレーノウハウで紹介されている設計状態となっていることを本書を読んで知りました。
    自分が設計を行う際はこれらは排除して正規形を意識したいと思います。

    難しかった点

  • グレーノウハウの使い所

    用法容量を守って使用する限りはシステムに良い作用を与えると記述がありましたが一朝一夕で判断出来るようなものではないと感じました。
    DB設計を行う際はグレーノウハウを使用していないかは気にしておき使用するにしても何となくではなく理解をして使用をしたいと思います。

おわりに

以上達人に学ぶDB設計を読んでの感想でした。
基礎ができるまではDB設計の時に読み返してある程度できるようになったらもう一歩踏み込んだDB設計の書籍にチャレンジしたいと思います。
ご閲覧いただきありがとうございました。

参考文献

スッキリわかるSQL入門を読んだ感想

はじめに

今回はスッキリわかるSQL入門を読了しましたので感想をまとめたいと思います。

良かった点

  • SQLの実行と結果の確認がブラウザで簡単にできるサービスが提供されていること

    初学者にはSQLの実行環境を用意するのも一苦労だと思いますがでどこでも簡単に実行結果を確認しながら学習できる点はよかったです。

  • 理解しやすい題材で順を追ってクエリを学ぶことができること

    家計簿のテーブルが題材となっておりとっつきやすかったです。
    またクエリも順序立てて説明されていました。

学びになった点

  • テーブルを正規化する流れ

    テーブル設計はやったことがないので勉強になりました。
    こちらもクエリ同様に家計の支出管理のDB設計を題材に順序立てて説明されていたので理解がしやすかったです。

難しかった点

  • 特になし

    自分が初学者の時に手に取りたかったと感じる一冊でした。
    理解もしやすくSQL学習の最初の一冊にはちょうど良いのではないかと思います。

おわりに

以上スッキリわかるSQL入門を読んでの感想でした。
設計部分はどこかで困った時に立ち返って読み返したいと思います。
ご閲覧いただきありがとうございました。

参考文献

プロを目指す人のためのRuby入門を読んだ感想

はじめに

今回はプロを目指す人のためのRuby入門(通称チェリー本)を読了したので感想をまとめたいと思います。

良かった点

  • 同じコードでもさまざまな記法がある中でスタンダードが示されていたこと

    本書では実装で複数の方法が取れる際に著者の経験的にどちらの使用頻度が多いや一般的にはこうであるように実際のところはどうなのかというのが所々示されていました。
    実装する際に記法に複数の選択肢がある場合に迷ってしまうことがありますが今回は現役バリバリrubyエンジニアのお墨付きなので間違い無いだろうという心持ちでした。

学びになった点

  • インデックスを作るという考え方

    著者は本書を読み進めるにあたり理解ができない内容は無理に理解しようとせず頭の中にインデックスを作成するスタイルで読み進めることをまえがきで推奨しています。
    私も章の途中で理解ができなかった箇所はこのインデックスを作成するスタイルで読み進めました。
    プログラミングに限らず新たに何かを学ぶ際にはこのスタイルを活用することで効率よく学習していけるのではないかと思いました。

  • rubyの基本的な文法について

    私は今までprogateでしかrubyを学習したことはありませんでした。
    本書で解説されているメソッドもprogateで見覚えがあったものがありましたが当時は処理の概要は理解できるものの記法についてはおまじない程度で覚えていました。
    その程度の理解で読み始めましたがそんな状態でも問題なく進めることができましたし基礎はある程度固めることができたと思います。

難しかった点

  • 8章モジュールを理解する

    8章の後半は理解できないことが多かったです。
    インデックスを作成するスタイルに切り替えて進めて行きました。
    必修の技術だと思うのでrubyのアウトプットなどを通じて理解を深め折を見て本章を読み返したいと思います。

おわりに

以上プロを目指す人のためのRuby入門を読んでの感想でした。
適宜読み直してしっかりと知識を定着させていきたいと思います。
ご閲覧いただきありがとうございました。

参考文献

既存のrailsアプリをdocker化する方法

はじめに

今回はDockerとdocker-composeについて学習したので既存のrailsアプリをdocker化する方法についてまとめます。
前提としてDocker、docker-composeはインストール済みとして進めていきます。

docker化までの流れ

以下の流れでdocker化を行います。

  • Dockerfile、docker-compose.ymlファイルを作成&編集
  • database.ymlファイルの編集
  • コンテナの立ち上げ&起動
  • アクセスできるかを確認

Dockerfile、docker-compose.ymlファイルを作成&編集

railsのプロジェクト直下にDockerfile、docker-compose.ymlファイルを作成します。

ファイル構成

Dockerfileに対し以下のように記述を行います。

FROM ruby:3.2.2
RUN  apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /rails_docker
WORKDIR /rails_docker
ADD Gemfile /rails_docker/
ADD Gemfile.lock /rails_docker/
RUN bundle install
ADD . /rails_docker

docker-compose.ymlに対し以下のように記述します。

version: '3'

volumes:
  db-data:

services:
  db:
    image: postgres:12
    environment:
      POSTGRES_PASSWORD: password
    volumes:
      - 'db-data:/var/lib/postgresql/data'

  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/rails_docker
    ports:
      - "3000:3000"
    depends_on:
      - db

docker-compose.ymlについて復習も兼ねて記載内容を解説します。

volumes:
  db-data:

db-dataという名前のボリュームを定義しています。
通常コンテナを破棄した際にコンテナで作成したデータは破棄されますがボリュームを設定することにより、ホスト側にデータを保存することができます。
定義したボリュームを他のコンテナからも参照することによりテストデータなどの共有を行うことができます。

services:
  db:
    image: postgres:12
    environment:
      POSTGRES_PASSWORD: password
    volumes:
      - 'db-data:/var/lib/postgresql/data'

services:でdbというサービス名を定義しています。
image:でビルドするイメージを指定しています。
environment:でコンテナに定義する環境変数を定義しています。
volumes:ボリューム:マウントするディレクトリの記法でフォルダをマウントしています。

  web:
    build: .
    command: >
      sh -c '
      rails db:create &&
      rails db:migrate &&
      bundle exec rails s -p 3000 -b '0.0.0.0'
      '
    volumes:
      - .:/rails_docker
    ports:
      - "3000:3000"
    depends_on:
      - db

build: .でホスト側に配置されたDockerfileをイメージに指定することができます。(.でカレントディレクトリのDockerfileが指定されています。)
command:でコンテナの環境で記載したコマンドを実行することができます。 (ポート番号3000番でローカルホストのブラウザに表示します。)

volumes:
  - .:/rails_docker

ボリュームが指定されていませんがこれはバインドマウントと言います。
ホスト側のカレントディレクトリとコンテナ側のrails_dockerディレクトリをマウントしています。
これによりコンテナ側のソースコードの変更などをホスト側でも確認することができます。

depends_on:
  - db

サービスの依存関係を表しており、dbを起動してからwebを起動することを表しています。

database.ymlファイルの編集

rails_docker/config/database.ymlに対し以下のように編集します。

default: &default
  adapter: postgresql
  encoding: unicode
  host: db
  username: postgres
  password: password
  # For details on connection pooling, see Rails configuration guide
  # https://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

変更点は以下の通りです。

  • db:の追加
  • username:の追加
  • password:の追加

コンテナの立ち上げ&起動

以上の手順で準備ができたのでコンテナの立ち上げ&起動 を行います。

#イメージしてコンテナの立ち上げ&起動
docker-compose up -d --build

#初回のみDBを作成する。
docker-compose run web rails db:migrate

#初回&DB定義変更時にmigrate実行
docker-compose run web rails db:migrate

アクセスできるかを確認

http://localhost:3000/にアクセスしてアプリ画面が確認できれば完了です。

おわりに

以上既存のrailsアプリをdocker化する方法でした。
Dockerを使用することにより環境構築が楽になることを実感できました。 ご閲覧いただきありがとうございました。

【初心者向け】GitHub Pages でWebページを公開する方法

はじめに

今回はGitHub Pagesを使ってWebページを公開する方法を学習しました。
備忘録を兼ねて手順をまとめます。

GitHub Pagesとは

GitHub Pagesとは自分で作ったWebページを無料で公開することのできるサービスです。 HTML/CSS/JSで作成したページを簡単に発信できます。

以下想定でページ公開方法の解説を進めていきます。

  • GitHubのアカウント登録が完了していること
  • ターミナルでgit の基本的なコマンドが使用できること

ページ公開までの流れ

  1. GitHubでリモートリポジトリを作成する
  2. 1で作成したリモートリポジトリに公開したいファイルをpushする
  3. 2でpushしたファイルをGitHub Pagesで公開設定を行う

1. GitHubでリモートリポジトリを作成する

①. サイト右上部のプラスボタンを押下する
②. 「New repsitory」を押下する

new repsitoryの作成方法

③. Repository nameに任意のリポジトリ名を入力する
④. 他の項目は画面の内容通りとしCreate repositoryボタンを押下する

repository新規作成画面

2. 1で作成したリモートリポジトリに公開したいファイルをpushする

①. リポジトリ作成画面から遷移した画面のSSHのURLをコピーする

新規リポジトリ作成ボタン押下後の遷移画面
②. ターミナルにてgit clone コピーしたSSHのURLでローカルにリモートリポジトリのクローンを作成する
ターミナルでgit cloneを実行する
③. ②で作成されたフォルダ内に公開したいファイルを追加し以下コマンドでリモートリポジトリにpushする

git add .

git commit -m "任意のコミットメッセージ"

git push -u origin main

3. 2でpushしたファイルをGitHub Pagesで公開設定を行う

①. 作成したリモートリポジトリから「Settings」を押下する

Settingsを押下する

②. 画面左部の「Pages」を押下する

Pagesを押下する

③. Branchでmainを選択し「Save」を押下する。
④. 「Visit site」を押下する。

GitHub Pages の公開

⑤. 公開完了!

公開したWebページ

おわりに

以上GitHub PagesでWebページを公開する手順の解説でした。
サーバーなどの煩雑な設定不要で公開までできますので非常に便利です。
ご閲覧いただきありがとうございました。

Linuxの基礎コマンドまとめ

はじめに

今回はLinuxの基礎コマンドを学習しました。
復習を兼ねて以下学んだコマンドを簡単ににまとめます。  

cd
pwd
ls
mkdir
rmdir
cat
less
tail
touch
rm
mv
cp
ln
find
chmod
chown
ps
kill

cd

書式 cd [ディレクトリ名]

pwd

書式 pwd

  • print working directory の略。
  • カレントディレクトリをフルパスで表示する。

ls

書式 ls [オプション] [ファイル]
オプション -a -l

  • list segments の略。
  • 指定されたファイルやディレクトリの一覧を取得できるコマンド
  • [ファイル]の指定がない場合はカレントディレクトリを検索する。
  • -aオプションで.から始まる隠しファイルを含めた一覧を取得できる。
  • -lオプションでファイルやディレクトリの詳細情報を含めた一覧を取得できる。

mkdir

書式 mkdir [ディレクトリ名]
オプション -p

  • make directory の略。
  • カレントディレクトリに指定した名前のディレクトリを作成する。
  • -pオプションでディレクトリをまとめて作成できる。
    (複数階層のディレクトリを作成したい場合オプションなしでmkdirコマンドを使用するとエラーとなる)

rmdir

書式 rmdir [ディレクトリ名]

  • remove directory の略。
  • 空のディレクトリを削除するコマンド。
  • ディレクトリが空でなければエラーとなるので安全に使用ができる。
  • rmコマンドのほうが使用される頻度は高い

cat

書式 cat [オプション名] [ファイル名]
オプション -n

  • concatenate の略。
  • ファイルの中身を表示するコマンド。
  • スペースで区切りファイルを2つ指定することで順番にファイルの中身を表示する。
  • -nオプションでファイルの中身に行番号を付与して表示する。

less

書式 less [オプション名] [ファイル名]

  • 長文のテキストの中身を確認するコマンドにはmoreとlessがある。
  • テキストファイルの中身を別タブで表示する。
  • 記述量が少ないものはcatコマンド多いものはlessコマンドでテキストを確認する。
  • 表示されたページでのコマンド操作
    • q ページを閉じる
    • ↑ 1行上に移動
    • ↓ 1行下に移動
    • f 1ページ進む
    • b 1ページ戻る
    • /hoge ↓方向に文字列検索
    • ?hoge ↑方向に文字列検索
    • n 次の検索候補に移動

tail

書式 tail [オプション名] [ファイル名]
オプション -n -f

  • ファイルの末尾を表示する。オプションで行数の指定がなければファイルの末尾から10行が表示される。
  • -nオプションで末尾から難行取得するか指定できる。(tail -n 5 hoge.txthoge.txtの末尾5行を取得)
  • -fオプションでコマンドのプロセスを待機させることができる。ファイルの末尾に書き込みがあるとリアルタイムで表示する。(ログなどに活用される)

touch

書式 touch [ファイル名]

  • ファイルのタイムスタンプを更新するコマンド。
  • ファイルが存在しなければ指定されたファイル名で作成する。

rm

書式 rm [オプション] [ファイル名]
オプション -r -i

  • ReMoveの略。
  • ファイルを削除するするコマンド。
  • -rオプションでディレクトリを削除対象として指定できる。
    (ディレクトリ配下のディレクトリ、ファイルをすべて削除する。)
  • -iオプションで削除を実行するかの確認を表示することができる。

mv

書式 mv [オプション] [移動元] [移動先]
オプション -i

  • moveの略。
  • ファイル名の変更、ファイルの移動を行う。
  • 移動元と移動先がファイルかディレクトリかで挙動が変わる。
    • ファイル×ファイル
      移動先の名前のファイルがあれば移動元で上書きする。
      移動先の名前のファイルがなければ移動先のファイルにファイル名が変更される。   
    • ファイル×ディレクト
      移動先のディレクトリの配下に移動元のファイルを移動する。
    • ディレクトリ×ファイル
      エラーとなる。
    • ディレクトリ×ディレクト
      移動元配下のファイルとディレクトリを移動先ディレクトリの配下に移動する。
  • iオプションで上書きを実行するかの確認を表示することができる。

cp

書式 cp [オプション] [コピー元] [コピー先]
オプション -r -i

  • copy の略。
  • コピー元のファイルのコピーをコピー先の名前で作成する。
  • 移動元と移動先がファイルかディレクトリかで挙動が変わる。
    • ファイル×ファイル
      コピー先のファイルがあればコピー元のファイルで内容を上書きする。
      コピー先のファイルがなければコピー先の名前でコピー元ファイルがコピーされる。
    • ファイル×ディレクト
      移動先のディレクトリの配下にコピー元のファイルのコピーを作成する。
    • ディレクトリ×ファイル
      エラーとなる。
    • ディレクトリ×ディレクトリ(-rオプションを使用する。)
      コピー元配下のファイルとディレクトリをコピー先ディレクトリの配下にコピーする。
  • -rオプションでディレクトリをコピー元に指定できるようになる。
  • -iオプションで上書きを実行するかの確認を表示することができる。

ln

書式 ln [オプション] [リンク元ファイル名] [リンク名]
オプション -s

  • linkの略。
  • ファイルに別名をつけることができる。(ハードリンク)
  • ファイルのパスを保持しファイルを参照できる。(シンボリックリンク
  • -sオプションでシンボリックリンクを作成する。
    (デフォルトはハードリンクが作成される。)

find

書式 find [検索開始ディレクトリ] [検索条件] [アクション]
検索条件 -name -iname -type
アクション -print

  • ファイルを検索する。
  • -nameの検索条件はファイル名の大文字小文字を区別する。
  • -inameの検索条件はファイル名の大文字小文字を区別しない。
  • -typeの検索条件はファイルの種類で検索ができる。
    -type f 通常ファイルを検索。
    -type l シンボリックリンクを検索。
    -type d ディレクトリを検索。
  • -printアクションで検索でヒットしたファイルのパスを表示する。(省略可能)

chmod

書式 chmod [対象] [+-=] [rwx] [ファイル名]

  • chang mode の略。
  • 対象は4つの権限から選択する。
    u 所有者の権限。
    g グループの権限。
    o その他ユーザーの権限。
    a 全ユーザーの権限。
  • [+-=]はの記号は以下を表している。
    + 権限を追加する。
    - 権限を削除する。
    = 指定された権限にする。
  • [rwx]の記号は以下を表している。
    r readの権限。
    w writeの権限。
    x excuteの権限。

chmodには数値で指定する記述方法もある。
書式 chmod [8進数の数値] [ファイル名]

  • 数値は左からオーナー、グループ、その他の権限を表す。
  • 数値は権限の数値の足し算で決まる。
権限 数値
r 4
w 2
x 1
  • コマンド例 chmod 755 hoge.txt

chown

書式 chown [オプション] [ユーザー名] [ファイル名]
オプション -h

  • change owner の略。
  • ファイルの所有権を変更する。
  • ユーザー名:グループ名とすることでグループの所有権も変更することができる。
  • -hオプションでシンボリックリンクの所有権を変更する。
    (リンク先ではない。)

ps

書式 ln [オプション名]
オプション aux

  • process status の略。
  • 実行中のプロセスを表示する。
  • auxオプション全ユーザーの全プロセスの詳細情報を表示する。
    (ハイフンは必要なし。)

kill

書式 kill [オプション名] %[ジョブID]
オプション -TERM(デフォルトで指定されている。)

  • ジョブやプロセスを終了させる。
    kill %1(%ジョブIDが1のジョブを終了)
    kill 10(プロセスIDが10のプロセスを終了)