「Railsで超簡単API」というQiita記事でAPIの勉強をしていたところ、名前空間という概念が出てきたので、まとめました。
Namespace(名前空間)とは
Namespaceとは名前の衝突を防ぐためにレイヤーを整理する概念のこと。Namespaceを使うと、名前が同じであっても、Namespaceが異なっていれば衝突が起きることがない。Namespaceは名字のようなもので、太郎という同じ名前の人間が二人いたとしても、山田太郎と上田太郎は名字が異なるため、概念の衝突を避けることが出来る。コードに起こすと下記のようなイメージ。
namespace YAMADA
{
name = "Taro"
}
namespace UEDA
{
name = "Taro"
}
put YAMADA::name
=> Taro
put UEDA::name
=> Taro
最後の出力結果は同じでになるが、出力されたTaroの定義元を見ると、AとBという別々の場所から参照されている。また、Namespaceの内容を別空間から呼ぶ場合は出所も一緒に明示する必要がある。
REST APIとGraphQLの特徴と相違点
REST APIとは
外部からプログラムを呼び出す際の規約の一つで、下記の原則に乗っ取る。
- ステートレスな管理(アクセス集中に耐えやすくするため）
- 命令系統の事前定義（HTTPのGETやPOSTメソッドなど）
- URLとメソッドでリソースを表現する
- 情報の内部に、複数の情報へのリンクをもたせることが出来る
#GraphQLとは
Facebook社が開発するWebAPI規格。GithubやNetflix、Airbnbなどが採用していることで有名。「クエリ言語」と「スキーマ言語」から成る。
クエリ言語には以下の3種類がある。
- データ取得系のquery
- データ更新系のmutation
- サーバーサイドのイベント通知のためのsubscription
スキーマ言語はGraphQLの仕様を記述するための言語。下記の様に、クエリの型を定義していく。
type Query {
currentUser: User!
}
type User {
id: ID!
name: String!
}
上記のようなスキーマに対して、下記のようなクエリを発行すると、JSON形式で内容が返ってくる。
query GetCurrentUser {
currentUser {
id
name
}
}
GraphQLの主な特徴は大きく3つ。
- クエリとレスポンスの構造の類似(GraphQLではJSONのなかの欲しいフィールドだけを指定することにより、レスポンスを軽くすることも可能)
- スキーマファーストの思想
- 単一エンドポイント
REST APIとGraphQLの比較
エンドポイントの数
RESTではエンドポイントが複数あるのに対し、GraphQLはエンドポイントが単一であることが特徴。RESTではURLにてエンドポイントを指定することで、リソースの明文化をすることが出来た。一方GraphQLは("POST /graphql")のような形で単一のエンドポイントだけが存在し、欲しいリソースはbodyの中に書く。
URIやHTTPS構造の使い方
RESTはURIやHTTPSでアクセス先を明確化する一方、GraphQLでは問い合わせ言語とスキーマ言語でアクセス内容を明確化する。
アクセス回数の制限
RESTではサーバー負荷の軽減の観点から1時間あたりのアクセス件数を制限するケースが多いが、GraphQLではこの制限がない。そのため、負荷の計算を自前で行う必要がある。
REST APIにおいてNamespaceの設定が重要な理由
RESTはエンドポイントが複数あるため、APIのURIの設定をわかりやすくするためにNamespaceを設定すると良い。また、この際にディレクトリの構成もNamespaceの構成と統一してあげる必要がある。
Rails.application.routes.draw do
namespace 'api' do
namespace 'v1' do
resources :posts
end
end
end
このようなNamespaceの構造を作った場合、下記のようなディレクトリ構成を設定する。
---- controllers
--- api
-- v1
- posts_controller.rb
ちなみにNamespaceを使わなくてもScopeで設定することも可能。
【Ruby on Rails】ルーティング scope と namespace の違い