「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 の違い