概要

nor.のシステムが外部に公開しているAPIの仕様書です。

リクエスト

すべてのAPIのURLは以下の形式で始まり、以降にAPIごとに異なるパスが続きます。

https://api.nordot.jp/v1.0/

以下は、URLの例です。

https://api.nordot.jp/v1.0/contentsholder/units.info

すべてのAPIのパラメータは、参照系APIはGETで、更新系APIはPOSTで渡します。
POSTの場合のリクエストボディは、application/x-www-form-urlencoded または multipart/ form-dataの形式で渡します。
これは、一般的なWebページのフォーム送信で使用される形式と同じです。
ただし、ファイルのアップロードを行う一部のAPIでは、multipart/form-dataの形式のみに対応しています。
パラメータの文字コードは、UTF8に対応しています。

レスポンス

すべてのAPIは、200番のステータスコードと一緒にレスポンスボディを返します。
レスポンスボディはJSONオブシェクトで返されます。
トップレベルのokプロパティは、処理が成功したか失敗したかを表わします(trueが成功、falseが失敗)。

成功時のレスポンスの例は、以下のとおりです。返すデータがあれば、okと一緒に返します。

HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/json; charset=utf-8
...

{
    "ok": true,
    "unit": {
        "id": "0123456",
        "name": "ノアドット新聞",
        ...
    }
}

失敗時のレスポンスの例は、以下のとおりです。errorプロパティでエラーコードを返します。
また、エラーについて補足情報がある場合は、error_detailプロパティも返す場合があります。

HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/json; charset=utf-8
...

{
    "ok": false,
    "error": "invalid_body",
    "error_detail": “markdown syntax error, near ’[[image](2345678’ on line 10",
}

共通エラー

すべてのAPIで共通のエラーコードは、以下のとおりです。
下記以外のエラーコードは、各APIの 詳細を参照してください。

エラーコード 説明
no_access_token 認証に必要なアクセストークンが渡されていない
invalid_access_token 不正なアクセストークン。フォーマットが不正、削除されたアクセストークン、権限のないユニットの情報を操作しようとした場合など。
server_error サーバ内部でのシステムエラー
service_unavailable 負荷やメンテナンスのため一時的に使用不可

認証

APIを使用するには、以下の手順で認証を行う必要があります。

1. nor.cmsでアクセストークンを発行

nor.が提供する管理ツール(nor.cms)にログインして、アクセストークンを発行します。
アクセストークン内部には、そのアクセストークンで操作できるユニットの情報を含んでいます。
アクセストークンの発行は最初に一度だけ行います。

2. アクセストークンを使用して目的のAPIを実行

取得したアクセストークンをAuthorizationヘッダーに付与して、目的のAPIを実行します。
以下はリクエストの例です。

GET /v1.0/contentsholder/posts.info HTTP/1.1
Host: api.nordot.jp
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
...

認証に成功すると、APIが正常に実行されてレスポンスが返さます。
アクセストークンが渡されなかった場合やアクセストークンが不正な場合は、エラーレスポンスが返されます。
以下は、エラーレスポンスの例です。エラーの詳細については、共通エラーの項目を参照してください。

{
    "ok": false,
    "error": "invalid_access_token"
}

以下は、アクセストークンに関する注意事項です。

アクセストークンは、漏洩するとAPIを自由に実行されてしまうため大切に管理してください。

アクセストークンの漏洩を防止するため、必ずSSL(https)を使用してAPIを実行してください。

万が一アクセストークンが漏洩してしまった場合には、nor.cmsで新しいアクセストークンを再発行できます。古いアクセストークンは使用できなくなります。

日時データとタイムゾーン

YYY-MM-DDTHH:MM:SS+hh:mm

RFC 3339は、コンピュータにおける日時の表現方法について定めた国際規格です。
協定世界時 (UTC)の場合、サフィックスとして"+00:00"を付加します。
地方時の場合は、協定世界時との 時差を"+09:00"のように付加します。

APIのリクエストパラメータで日時データを送信する場合は、任意のタイムゾーンを使用できます。
例えば、以下の2つはタイムゾーンは異なっても同じ日時を表しているため、どちらをパラメータで送信した場合も、
APIでは同じ日時と判断して処理が行われます。

2015-10-10T04:50:40+00:00 # 協定世界時の2015年10月10日4時50分40秒
2015-10-10T13:50:40+09:00 # 日本時間の2015年10月10日13時50分40秒

APIのレスポンスで返される日時データは、すべて協定世界時のタイムゾーンで返されます。
そのため、地方時で使用したい場合はAPI利用者側で地方時に変換する必要があります。
以下は、レスポンスで返されたcreated_atとupdated_atの値の例です。

{
    "created_at": "2015-11-10T20:09:31+00:00",
    "updated_at": "2015-12-25T18:58:10+00:00",
    ...
}

リクエスト頻度についての注意事項

本APIへのリクエストに際して、現在のところ上限回数は設けていません。ただし、過度なリクエストはサーバーの過負荷に繋がるため、繰り返しリクエストする場合は、リクエストごとに1秒以上の間隔をあけるなど、サーバーリソースの節約にご協力ください。

過度なリクエストによってシステムへの影響が懸念される場合は、予告なくリクエストを制限する場合があります。

将来のバージョンでは、単位時間当たりのリクエスト数の自動制限機能(Rate Limit機能)を導入する予定です。