Browse Source

guide-ja/rest-* revised [ci skip] (#16194)

tags/2.0.16
Nobuo Kihara 6 years ago committed by Alexander Makarov
parent
commit
3a1165973a
  1. 35
      docs/guide-ja/rest-authentication.md
  2. 28
      docs/guide-ja/rest-controllers.md
  3. 22
      docs/guide-ja/rest-error-handling.md
  4. 19
      docs/guide-ja/rest-quick-start.md
  5. 52
      docs/guide-ja/rest-resources.md
  6. 19
      docs/guide-ja/rest-routing.md
  7. 33
      docs/guide-ja/rest-versioning.md

35
docs/guide-ja/rest-authentication.md

@ -5,15 +5,21 @@
これは、セッションやクッキーは使用すべきでないことを意味します。
従って、ユーザの認証ステータスをセッションやクッキーで保持することが出来ないため、全てのリクエストに何らかの認証情報を付加する必要があります。
通常使われるのは、ユーザを認証するための秘密のアクセス・トークンを全てのリクエストとともに送信する方法です。
アクセス・トークンはユーザを一意に特定して認証することが出来るものですので、**API リクエストは、中間者攻撃 (man-in-the-middle attack) を防止するために、常に HTTPS 経由で送信されなければなりません**。
アクセス・トークンはユーザを一意に特定して認証することが出来るものですので、
**API リクエストは、中間者攻撃 (man-in-the-middle attack) を防止するために、常に HTTPS 経由で送信されなければなりません**。
アクセス・トークンを送信するには、いくつかの異なる方法があります。
* [HTTP Basic 認証](http://ja.wikipedia.org/wiki/Basic%E8%AA%8D%E8%A8%BC): アクセス・トークンはユーザ名として送信されます。
この方法は、アクセス・トークンを API コンシューマ側で安全に保存することが出来る場合、例えば API コンシューマがサーバ上で走るプログラムである場合などにのみ使用されるべきです。
* クエリ・パラメータ: アクセス・トークンは API の URL、例えば、`https://example.com/users?access-token=xxxxxxxx` でクエリ・パラメータとして送信されます。
ほとんどのウェブ・サーバはクエリ・パラメータをサーバのログに記録するため、この手法は、アクセス・トークンを HTTP ヘッダを使って送信することができない `JSONP` リクエストに応答するために主として使用されるべきです。
* [OAuth 2](http://oauth.net/2/): OAuth2 プロトコルに従って、アクセス・トークンはコンシューマによって権限付与サーバから取得され、[HTTP Bearer Tokens](http://tools.ietf.org/html/rfc6750) 経由で API サーバに送信されます。
この方法は、アクセス・トークンを API コンシューマ側で安全に保存することが出来る場合、
例えば API コンシューマがサーバ上で走るプログラムである場合などにのみ使用されるべきです。
* クエリ・パラメータ: アクセス・トークンは API の URL、例えば、`https://example.com/users?access-token=xxxxxxxx`
でクエリ・パラメータとして送信されます。
ほとんどのウェブ・サーバはクエリ・パラメータをサーバのログに記録するため、この手法は、
アクセス・トークンを HTTP ヘッダを使って送信することができない `JSONP` リクエストに応答するために主として使用されるべきです。
* [OAuth 2](http://oauth.net/2/): OAuth2 プロトコルに従って、
アクセス・トークンはコンシューマによって権限付与サーバから取得され、[HTTP Bearer Tokens](http://tools.ietf.org/html/rfc6750) 経由で
API サーバに送信されます。
Yii は上記の全ての認証方法をサポートしています。新しい認証方法を作成することも簡単に出来ます。
@ -22,15 +28,18 @@ Yii は上記の全ての認証方法をサポートしています。新しい
1. `user` [アプリケーション・コンポーネント](structure-application-components.md) を構成します。
- [[yii\web\User::enableSession|enableSession]] プロパティを `false` に設定します。
- [[yii\web\User::loginUrl|loginUrl]] プロパティを `null` に設定し、ログインページにリダイレクトする代りに HTTP 403 エラーを表示します。
2. REST コントローラ・クラスにおいて、`authenticator` ビヘイビアを構成することによって、どの認証方法を使用するかを指定します。
2. REST コントローラ・クラスにおいて、`authenticator` ビヘイビアを構成することによって、
どの認証方法を使用するかを指定します。
3. [[yii\web\User::identityClass|ユーザ・アイデンティティ・クラス]] において [[yii\web\IdentityInterface::findIdentityByAccessToken()]] を実装します。
ステップ 1 は必須ではありませんが、ステート・レスであるべき RESTful API のために推奨されます。
[[yii\web\User::enableSession|enableSession]] が `false` である場合、ユーザの認証ステータスがセッションを使ってリクエストをまたいで存続することはありません。
その代りに、すべてのリクエストに対して認証が実行されます。このことは、ステップ 2 と 3 によって達成されます。
> Tip: RESTful API をアプリケーションの形式で開発する場合は、アプリケーションの構成情報で `user` アプリケーション・コンポーネント(structure-application-components.md) の [[yii\web\User::enableSession|enableSession]] プロパティを構成することが出来ます。
> Tip: RESTful API をアプリケーションの形式で開発する場合は、アプリケーションの構成情報で `user` アプリケーション・コンポーネント(structure-application-components.md)
> [[yii\web\User::enableSession|enableSession]] プロパティを構成することが出来ます。
> RESTful API をモジュールとして開発する場合は、次のように、モジュールの `init()` メソッドに一行を追加することが出来ます。
>
> ```php
> public function init()
> {
@ -97,18 +106,22 @@ class User extends ActiveRecord implements IdentityInterface
}
```
上記のように認証が有効化された後は、全ての API リクエストに対して、リクエストされたコントローラが `beforeAction()` の段階でユーザを認証することを試みます。
上記のように認証が有効化された後は、全ての API リクエストに対して、リクエストされたコントローラ
`beforeAction()` の段階でユーザを認証することを試みます。
認証が成功すると、コントローラはその他のチェック (レート制限、権限付与など) をしてから、アクションを実行します。
認証されたユーザのアイデンティティは `Yii::$app->user->identity` によって取得することが出来ます。
認証が失敗したときは、HTTP ステータス 401 およびその他の適切なヘッダ (HTTP Basic 認証に対する `WWW-Authenticate` ヘッダなど) を持つレスポンスが送り返されます。
認証が失敗したときは、HTTP ステータス 401 およびその他の適切なヘッダ (HTTP Basic 認証に対する `WWW-Authenticate` ヘッダなど)
を持つレスポンスが送り返されます。
## 権限付与 <span id="authorization"></span>
ユーザが認証された後、おそらくは、リクエストされたリソースに対してリクエストされたアクションを実行する許可を彼または彼女が持っているかどうかをチェックしたいでしょう。
ユーザが認証された後、おそらくは、リクエストされたリソースに対してリクエストされたアクションを実行する許可を
彼または彼女が持っているかどうかをチェックしたいでしょう。
*権限付与* と呼ばれるこのプロセスについては、[権限付与](security-authorization.md) のセクションで詳細に説明されています。
あなたのコントローラが [[yii\rest\ActiveController]] から拡張したものである場合は、[[yii\rest\ActiveController::checkAccess()|checkAccess()]] メソッドをオーバーライドして権限付与のチェックを実行することが出来ます。
あなたのコントローラが [[yii\rest\ActiveController]] から拡張したものである場合は、
[[yii\rest\ActiveController::checkAccess()|checkAccess()]] メソッドをオーバーライドして権限付与のチェックを実行することが出来ます。
このメソッドが [[yii\rest\ActiveController]] によって提供されている内蔵のアクションから呼び出されます。

28
docs/guide-ja/rest-controllers.md

@ -1,12 +1,14 @@
コントローラ
============
リソース・クラスを作成して、リソース・データをどのようにフォーマットすべきかを指定したら、次は、RESTful API を通じてエンド・ユーザにリソースを公開するコントローラ・アクションを作成します。
リソース・クラスを作成して、リソース・データをどのようにフォーマットすべきかを指定したら、
次は、RESTful API を通じてエンド・ユーザにリソースを公開するコントローラ・アクションを作成します。
Yii は、RESTful アクションを作成する仕事を簡単にするための二つの基底コントローラ・クラスを提供しています。
すなわち、[[yii\rest\Controller]] と [[yii\rest\ActiveController]] です。
二つのコントローラの違いは、後者は [アクティブ・レコード](db-active-record.md) として表現されるリソースの扱いに特化した一連のアクションをデフォルトで提供する、という点にあります。
従って、あなたが [アクティブ・レコード](db-active-record.md) を使っていて、提供される組み込みのアクションに満足できるのであれば、コントローラ・クラスを [[yii\rest\ActiveController]] から拡張することを検討すると良いでしょう。
従って、あなたが [アクティブ・レコード](db-active-record.md) を使っていて、提供される組み込みのアクションに満足できるのであれば、
コントローラ・クラスを [[yii\rest\ActiveController]] から拡張することを検討すると良いでしょう。
そうすれば、最小限のコードで強力な RESTful API を作成することが出来ます。
[[yii\rest\Controller]] と [[yii\rest\ActiveController]] は、ともに、下記の機能を提供します。
@ -25,12 +27,14 @@ Yii は、RESTful アクションを作成する仕事を簡単にするため
## コントローラ・クラスを作成する <span id="creating-controller"></span>
新しいコントローラ・クラスを作成する場合、コントローラ・クラスの命名規約は、リソースの型の名前を単数形で使う、というものです。
新しいコントローラ・クラスを作成する場合、コントローラ・クラスの命名規約は、
リソースの型の名前を単数形で使う、というものです。
例えば、ユーザの情報を提供するコントローラは `UserController` と名付けることが出来ます。
新しいアクションを作成する仕方はウェブ・アプリケーションの場合とほぼ同じです。
唯一の違いは、`render()` メソッドを呼んでビューを使って結果を表示する代りに、RESTful アクションの場合はデータを直接に返す、という点です。
[[yii\rest\Controller::serializer|シリアライザ]] と [[yii\web\Response|レスポンス・オブジェクト]] が、元のデータからリクエストされた形式への変換を処理します。
[[yii\rest\Controller::serializer|シリアライザ]] と [[yii\web\Response|レスポンス・オブジェクト]] が、
元のデータからリクエストされた形式への変換を処理します。
例えば、
```php
@ -71,14 +75,15 @@ public function behaviors()
}
```
### CORS <span id="cors"></span>
コントローラに [CORS (クロス・オリジン・リソース共有)](structure-filters.md#cors) フィルタを追加するのは、上記の他のフィルタを追加するのより、若干複雑になります。
と言うのは、CORS フィルタは認証メソッドより前に適用されなければならないため、他のフィルタとは少し異なるアプローチが必要だからです。
また、ブラウザが認証クレデンシャルを送信する必要なく、リクエストが出来るかどうかを前もって安全に判断できるように、
[CORS プリフライト・リクエスト](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests) の認証を無効にする必要もあります。
下記のコードは、[[yii\rest\ActiveController]] を拡張した既存のコントローラに [[yii\filters\Cors]] フィルタを追加するのに必要なコードを示しています。
[CORS プリフライト・リクエスト](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests)
の認証を無効にする必要もあります。
下記のコードは、[[yii\rest\ActiveController]] を拡張した既存のコントローラに
[[yii\filters\Cors]] フィルタを追加するのに必要なコードを示しています。
```php
use yii\filters\auth\HttpBasicAuth;
@ -108,7 +113,8 @@ public function behaviors()
## `ActiveController` を拡張する <span id="extending-active-controller"></span>
コントローラを [[yii\rest\ActiveController]] から拡張する場合は、このコントローラを通じて提供しようとしているリソース・クラスの名前を [[yii\rest\ActiveController::modelClass|modelClass]] プロパティにセットしなければなりません。
コントローラを [[yii\rest\ActiveController]] から拡張する場合は、このコントローラを通じて提供しようとしているリソース・クラスの名前を
[[yii\rest\ActiveController::modelClass|modelClass]] プロパティにセットしなければなりません。
リソース・クラスは [[yii\db\ActiveRecord]] から拡張しなければなりません。
@ -124,8 +130,7 @@ public function behaviors()
* [[yii\rest\OptionsAction|options]]: サポートされている HTTP メソッドを返す。
これらのアクションは全て [[yii\rest\ActiveController::actions()|actions()]] メソッドによって宣言されます。
`actions()` メソッドをオーバーライドすることによって、これらのアクションを構成したり、そのいくつかを無効化したりすることが出来ます。
例えば、
`actions()` メソッドをオーバーライドすることによって、これらのアクションを構成したり、そのいくつかを無効化したりすることが出来ます。例えば、
```php
public function actions()
@ -152,7 +157,8 @@ public function prepareDataProvider()
### アクセス・チェックを実行する <span id="performing-access-check"></span>
RESTful API によってリソースを公開するときには、たいてい、現在のユーザがリクエストしているリソースにアクセスしたり操作したりする許可を持っているか否かをチェックする必要があります。
RESTful API によってリソースを公開するときには、たいてい、
現在のユーザがリクエストしているリソースにアクセスしたり操作したりする許可を持っているか否かをチェックする必要があります。
これは、[[yii\rest\ActiveController]] を使う場合は、[[yii\rest\ActiveController::checkAccess()|checkAccess()]] メソッドを次のようにオーバーライドすることによって出来ます。
```php

22
docs/guide-ja/rest-error-handling.md

@ -1,11 +1,13 @@
エラー処理
==========
RESTful API リクエストを処理していて、ユーザのリクエストにエラーがあったり、何か予期しないことがサーバ上で起ったりしたときには、単に例外を投げて、ユーザに何かがうまく行かなかったことを知らせることも出来ます。
しかし、エラーの原因 (例えば、リクエストされたリソースが存在しない、など) を特定することが出来るなら、適切な HTTP ステータス・コード (例えば、404 ステータス・コードを表わす [[yii\web\NotFoundHttpException]]) と一緒に例外を投げることを検討すべきです。
RESTful API リクエストを処理していて、ユーザのリクエストにエラーがあったり、何か予期しないことがサーバ上で起ったりしたときには、
単に例外を投げて、ユーザに何かがうまく行かなかったことを知らせることも出来ます。
しかし、エラーの原因 (例えば、リクエストされたリソースが存在しない、など) を特定することが出来るなら、
適切な HTTP ステータス・コード (例えば、404 ステータス・コードを表わす [[yii\web\NotFoundHttpException]])
と一緒に例外を投げることを検討すべきです。
そうすれば、Yii は対応する HTTP ステータスのコードとテキストをレスポンスとともに送信します。
Yii はまた、レスポンス・ボディにも、シリアライズされた表現形式の例外を含めます。
例えば、
Yii はまた、レスポンス・ボディにも、シリアライズされた表現形式の例外を含めます。例えば、
```
HTTP/1.1 404 Not Found
@ -29,14 +31,14 @@ Content-Type: application/json; charset=UTF-8
`Location` ヘッダが、新しく作成されたリソースを指し示す URL を含んでいます。
* `204`: リクエストは成功裡に処理されましたが、レスポンスはボディ・コンテントを含んでいません (`DELTE` リクエストなどの場合)。
* `304`: リソースは修正されていません。キャッシュしたバージョンを使うことが可能です。
* `400`: 無効なリクエストです。これはユーザのさまざまな行為によって引き起こされます。例えば、リクエストのボディに無効な JSON データを入れたり、無効なアクションパラメータを指定したり、など。
* `400`: 無効なリクエストです。これはユーザのさまざまな行為によって引き起こされます。
例えば、リクエストのボディに無効な JSON データを入れたり、無効なアクションパラメータを指定したり、など。
* `401`: 認証が失敗しました。
* `403`: 認証されたユーザは指定された API エンド・ボイントにアクセスすることを許可されていません。
* `404`: リクエストされたリソースは存在しません。
* `405`: メソッドが許可されていません。どの HTTP メソッドが許可されているか、`Allow` ヘッダをチェックしてください。
* `415`: サポートされていないメディア・タイプです。リクエストされたコンテント・タイプまたはバージョン番号が無効です。
* `422`: データの検証が失敗しました (例えば `POST` リクエストに対するレスポンスで)。
レスポンス・ボディで詳細なエラー・メッセージをチェックしてください。
* `422`: データの検証が失敗しました (例えば `POST` リクエストに対するレスポンスで)。レスポンス・ボディで詳細なエラー・メッセージをチェックしてください。
* `429`: リクエストの数が多すぎます。レート制限のためにリクエストが拒絶されました。
* `500`: 内部的サーバエラー。これは内部的なプログラムエラーによって生じ得ます。
@ -44,7 +46,8 @@ Content-Type: application/json; charset=UTF-8
## エラー・レスポンスをカスタマイズする <span id="customizing-error-response"></span>
場合によっては、デフォルトのエラー・レスポンス形式をカスタマイズしたいことがあるでしょう。
例えば、さまざまな HTTP ステータスを使ってさまざまなエラーを示すという方法によるのではなく、次に示すように、HTTP ステータスとしては常に 200 を使い、実際の HTTP ステータス・コードはレスポンスの JSON 構造の一部として包み込む、という方式です。
例えば、さまざまな HTTP ステータスを使ってさまざまなエラーを示すという方法によるのではなく、次に示すように、
HTTP ステータスとしては常に 200 を使い、実際の HTTP ステータス・コードはレスポンスの JSON 構造の一部として包み込む、という方式です。
```
HTTP/1.1 200 OK
@ -87,4 +90,5 @@ return [
];
```
上記のコードは、`suppress_response_code` が `GET` のパラメータとして渡された場合に、レスポンスを (成功したものも、失敗したものも) 上記で説明したように再フォーマットします。
上記のコードは、`suppress_response_code` が `GET` のパラメータとして渡された場合に、
レスポンスを (成功したものも、失敗したものも) 上記で説明したように再フォーマットします。

19
docs/guide-ja/rest-quick-start.md

@ -39,10 +39,8 @@ class UserController extends ActiveController
```
このコントローラ・クラスは、よく使用される一揃いの RESTful アクションを実装した [[yii\rest\ActiveController]] を拡張するものです。
[[yii\rest\ActiveController::modelClass|modelClass]] を `app\models\User` と指定することによって、データの取得と操作にどのモデルが使用できるかをコントローラに教えてやります。
The controller class extends from [[yii\rest\ActiveController]], which implements a common set of RESTful actions.
By specifying [[yii\rest\ActiveController::modelClass|modelClass]]
as `app\models\User`, the controller knows which model can be used for fetching and manipulating data.
[[yii\rest\ActiveController::modelClass|modelClass]] として `app\models\User` が指定されているため、
コントローラがどのモデルを使用してデータの取得と操作が出来るかがわかります。
## URL 規則を構成する <span id="configuring-url-rules"></span>
@ -60,8 +58,8 @@ as `app\models\User`, the controller knows which model can be used for fetching
]
```
上記の構成情報は、主として、`user` コントローラの URL 規則を追加して、ユーザのデータが綺麗な URL と意味のある HTTP 動詞によってアクセスおよび操作できるようにするものです。
上記の構成情報は、主として、`user` コントローラの URL 規則を追加して、ユーザのデータが綺麗な URL と意味のある
HTTP 動詞によってアクセスおよび操作できるようにするものです。
> Info: Yii はコントローラの名前を自動的に複数形にしてエンド・ボイントとして使用します (下の「試してみる」(#trying-it-out) を参照してください)。
> この振る舞いは [[yii\rest\UrlRule::$pluralize]] プロパティを使って構成することが可能です。
@ -69,7 +67,8 @@ as `app\models\User`, the controller knows which model can be used for fetching
## JSON の入力を可能にする <span id="enabling-json-input"></span>
API が JSON 形式で入力データを受け取ることが出来るように、`request` [アプリケーション・コンポーネント](structure-application-components.md) の [[yii\web\Request::$parsers|parsers]] プロパティを構成して、JSON 入力のために [[yii\web\JsonParser]] を使うようにします。
API が JSON 形式で入力データを受け取ることが出来るように、`request` [アプリケーション・コンポーネント](structure-application-components.md) の
[[yii\web\Request::$parsers|parsers]] プロパティを構成して、JSON 入力のために [[yii\web\JsonParser]] を使うようにします。
```php
'request' => [
@ -201,8 +200,10 @@ Yii の RESTful API フレームワークを使う場合は、API エンド・
そして、コントローラを使って、単一タイプのリソースに対するエンド・ボイントを実装するアクションを編成します。
リソースは [[yii\base\Model]] クラスを拡張するデータ・モデルとして表現されます。
データベース (リレーショナルまたは NoSQL) を扱っている場合は、[[yii\db\ActiveRecord|ActiveRecord]] を使ってリソースを表現することが推奨されます。
データベース (リレーショナルまたは NoSQL) を扱っている場合は、[[yii\db\ActiveRecord|ActiveRecord]]
を使ってリソースを表現することが推奨されます。
[[yii\rest\UrlRule]] を使って API エンド・ボイントへのルーティングを簡単にすることが出来ます。
これは要求されてはいませんが、RESTful API は、保守を容易にするために、ウェブのフロントエンドやバックエンドとは別の独立したアプリケーションとして開発することが推奨されます。
これは要求されてはいませんが、RESTful API は、保守を容易にするために、
ウェブのフロントエンドやバックエンドとは別の独立したアプリケーションとして開発することが推奨されます。

52
docs/guide-ja/rest-resources.md

@ -4,7 +4,9 @@
RESTful API は、つまるところ、*リソース* にアクセスし、それを操作するものです。
MVC の枠組の中では、リソースは [モデル](structure-models.md) として見ることが出来ます。
リソースをどのように表現すべきかについて制約がある訳ではありませんが、Yii においては、通常は、次のような理由によって、リソースを [[yii\base\Model]] またはその子クラス (例えば [[yii\db\ActiveRecord]]) のオブジェクトとして表現することになります。
リソースをどのように表現すべきかについて制約がある訳ではありませんが、
Yii においては、通常は、次のような理由によって、リソースを [[yii\base\Model]] またはその子クラス (例えば [[yii\db\ActiveRecord]])
のオブジェクトとして表現することになります。
* [[yii\base\Model]] は [[yii\base\Arrayable]] インタフェイスを実装しています。
これによって、リソースのデータを RESTful API を通じて公開する仕方をカスタマイズすることが出来ます。
@ -13,7 +15,8 @@ MVC の枠組の中では、リソースは [モデル](structure-models.md) と
* [[yii\db\ActiveRecord]] は DB データのアクセスと操作に対する強力なサポートを提供しています。
リソース・データがデータベースに保存されているときは、アクティブ・レコードが最適の選択です。
このセクションでは、主として、[[yii\base\Model]] クラス (またはその子クラス) から拡張したリソース・クラスにおいて、RESTful API を通じて返すことが出来るデータを指定する方法を説明します。
このセクションでは、主として、[[yii\base\Model]] クラス (またはその子クラス) から拡張したリソース・クラスにおいて、
RESTful API を通じて返すことが出来るデータを指定する方法を説明します。
リソース・クラスが [[yii\base\Model]] から拡張したものでない場合は、全てのパブリックなメンバ変数が返されます。
@ -25,41 +28,41 @@ Yii はこのプロセスを二つのステップに分けます。
次に、その配列が [[yii\web\ResponseFormatterInterface|レスポンス・フォーマッタ]] によって、リクエストされた形式 (例えば JSON や XML) の文字列にシリアライズされます。
リソース・クラスを開発するときに主として力を注ぐべきなのは、最初のステップです。
[[yii\base\Model::fields()|fields()]] および/または [[yii\base\Model::extraFields()|extraFields()]] をオーバーライドすることによって、リソースのどういうデータ (*フィールド* と呼ばれます) を配列表現に入れることが出来るかを指定することが出来ます。
この二つのメソッドの違いは、前者が配列表現に含まれるべきフィールドのデフォルトのセットを指定するのに対して、後者はエンド・ユーザが `expand` クエリ・パラメータで要求したときに配列に含めることが出来る追加のフィールドを指定する、という点にあります。
例えば、
[[yii\base\Model::fields()|fields()]] および/または [[yii\base\Model::extraFields()|extraFields()]] をオーバーライドすることによって、
リソースのどういうデータ (*フィールド* と呼ばれます) を配列表現に入れることが出来るかを指定することが出来ます。
この二つのメソッドの違いは、前者が配列表現に含まれるべきフィールドのデフォルトのセットを指定するのに対して、
後者はエンド・ユーザが `expand` クエリ・パラメータで要求したときに配列に含めることが出来る追加のフィールドを指定する、
という点にあります。例えば、
```
// fields() 宣言されている全てのフィールドを返す。
// fields() 宣言されている全てのフィールドを返す。
http://localhost/users
// "id" と "email" のフィールドだけを返す (ただし、fields() で宣言されているなら) 。
// "id" と "email" のフィールドだけを返す (ただし、fields() で宣言されていれば) 。
http://localhost/users?fields=id,email
// fields() の全てのフィールドと "profile" のフィールドを返す (ただし、"profile" が extraFields() で宣言されているなら)。
// fields() の全てのフィールドと "profile" のフィールドを返す (ただし、"profile" が extraFields() で宣言されていれば)。
http://localhost/users?expand=profile
// fields() の全てのフィールドと post の "author" フィールドを返す
// (ただし、"author" が post モデルの extraFields() にあれば)。
http://localhost/comments?expand=post.author
// "id"、"email"、"profile" のフィールドだけを返す
// (ただし、"id" と "email" が fields() で宣言されており、
// "profile" が extraFields() で宣言されているなら)。
// "id" と"email" (ただし、fileds() で宣言されていれば) と
// "profile" (ただし、extraFields() で宣言されていれば) を返す。
http://localhost/users?fields=id,email&expand=profile
```
### fields()` をオーバーライドする <span id="overriding-fields"></span>
デフォルトでは、[[yii\base\Model::fields()]] は、モデルの全ての属性をフィールドとして返し、[[yii\db\ActiveRecord::fields()]] は、DB から投入された属性だけを返します。
デフォルトでは、[[yii\base\Model::fields()]] は、モデルの全ての属性をフィールドとして返し、
[[yii\db\ActiveRecord::fields()]] は、DB から投入された属性だけを返します。
`fields()` をオーバーライドして、フィールドを追加、削除、名前変更、または再定義することが出来ます。
`fields()` の返り値は配列でなければなりません。
配列のキーはフィールド名であり、配列の値は対応するフィールドの定義です。
フィールドの定義は、プロパティ/属性の名前か、あるいは、対応するフィールドの値を返す無名関数とすることが出来ます。
フィールド名がそれを定義する属性名と同一であるという特殊な場合においては、配列のキーを省略することが出来ます。
例えば、
フィールド名がそれを定義する属性名と同一であるという特殊な場合においては、配列のキーを省略することが出来ます。例えば、
```php
// 明示的に全てのフィールドをリストする方法。(API の後方互換性を保つために) DB テーブルやモデル属性の
@ -99,7 +102,8 @@ public function fields()
### `extraFields()` をオーバーライドする<span id="overriding-extra-fields"></span>
デフォルトでは、[[yii\base\Model::extraFields()]] は空の配列を返し、[[yii\db\ActiveRecord::extraFields()]] は DB から取得されたリレーションの名前を返します。
デフォルトでは、[[yii\base\Model::extraFields()]] は空の配列を返し、[[yii\db\ActiveRecord::extraFields()]]
は DB から取得されたリレーションの名前を返します。
`extraFields()` によって返されるデータの形式は `fields()` のそれと同じです。
通常、`extraFields()` は、主として、値がオブジェクトであるフィールドを指定するのに使用されます。
@ -138,12 +142,12 @@ public function extraFields()
[HATEOAS](http://en.wikipedia.org/wiki/HATEOAS) は、Hypermedia as the Engine of Application State (アプリケーション状態のエンジンとしてのハイパーメディア) の略称です。
HATEOAS は、RESTful API は自分が返すリソースについて、どのようなアクションがサポートされているかをクライアントが発見できるような情報を返すべきである、という概念です。
HATEOAS のキーポイントは、リソース・データが API によって提供されるときには、関連する情報を一群のハイパーリンクによって返すべきである、ということです。
HATEOAS のキーポイントは、リソース・データが API によって提供されるときには、
関連する情報を一群のハイパーリンクによって返すべきである、ということです。
あなたのリソース・クラスは、[[yii\web\Linkable]] インタフェイスを実装することによって、HATEOAS をサポートすることが出来ます。
このインタフェイスは、[[yii\web\Link|リンク]] のリストを返すべき [[yii\web\Linkable::getLinks()|getLinks()]] メソッド一つだけを含みます。
典型的には、少なくとも、リソース・オブジェクトそのものへの URL を表現する `self` リンクを返さなければなりません。
例えば、
典型的には、少なくとも、リソース・オブジェクトそのものへの URL を表現する `self` リンクを返さなければなりません。例えば、
```php
use yii\base\Model;
@ -234,7 +238,8 @@ class PostController extends Controller
}
```
データ・プロバイダが RESTful API のレスポンスで送信される場合は、[[yii\rest\Serializer]] が現在のページのリソースを取り出して、リソース・オブジェクトの配列としてシリアライズします。
データ・プロバイダが RESTful API のレスポンスで送信される場合は、[[yii\rest\Serializer]]
が現在のページのリソースを取り出して、リソース・オブジェクトの配列としてシリアライズします。
それだけでなく、[[yii\rest\Serializer]] は次の HTTP ヘッダを使ってページネーション情報もレスポンスに含めます。
* `X-Pagination-Total-Count`: リソースの総数
@ -247,7 +252,10 @@ REST API におけるコレクションはデータ・プロバイダである
その一例を [クイック・スタート](rest-quick-start.md#trying-it-out) のセクションで見ることが出来ます。
バージョン 2.0.13 以降、Yii はコレクションをフィルターする便利な機能を提供しています。
### コレクションをフィルタリングする <span id="filtering-collections"></span>
バージョン 2.0.13 以降、Yii はコレクションをフィルタリングする便利な機能を提供しています。
その一例を [クイック・スタート](rest-quick-start.md#trying-it-out) のガイドに見ることが出来ます。
エンド・ボイントをあなた自身が実装しようとしている場合、フィルタリングは
データ・プロバイダのガイドの [データフィルタを使ってデータ・プロバイダをフィルタリングする](output-data-providers.md#filtering-data-providers-using-data-filters) のセクションで述べられている方法で行うことが出来ます。
データ・プロバイダのガイドの [データ・フィルタを使ってデータ・プロバイダをフィルタリングする](output-data-providers.md#filtering-data-providers-using-data-filters
のセクションで述べられている方法で行うことが出来ます。

19
docs/guide-ja/rest-routing.md

@ -1,11 +1,13 @@
ルーティング
============
リソースとコントローラのクラスが準備できたら、通常のウェブ・アプリケーションと同じように、`http://localhost/index.php?r=user/create` というような URL を使ってリソースにアクセスすることが出来ます。
リソースとコントローラのクラスが準備できたら、通常のウェブ・アプリケーションと同じように、
`http://localhost/index.php?r=user/create` というような URL を使ってリソースにアクセスすることが出来ます。
実際には、綺麗な URL を有効にして HTTP 動詞を利用したいというのが普通でしょう。
例えば、`POST /users` というリクエストが `user/create` アクションへのアクセスを意味するようにする訳です。
これは、アプリケーションの構成情報で `urlManager` [アプリケーション・コンポーネント](structure-application-components.md) を次のように構成することによって容易に達成することが出来ます。
これは、アプリケーションの構成情報で `urlManager` [アプリケーション・コンポーネント](structure-application-components.md)
を次のように構成することによって容易に達成することが出来ます。
```php
'urlManager' => [
@ -18,7 +20,8 @@
]
```
ウェブ・アプリケーションの URL 管理と比べたときに、上記で目に付く新しいことは、RESTful API リクエストのルーティングに [[yii\rest\UrlRule]] を使用していることです。
ウェブ・アプリケーションの URL 管理と比べたときに、上記で目に付く新しいことは、
RESTful API リクエストのルーティングに [[yii\rest\UrlRule]] を使用していることです。
この特殊な URL 規則クラスが、一揃いの子 URL 規則を作成して、指定されたコントローラのルーティングと URL 生成をサポートします。
例えば、上記のコードは、おおむね下記の規則と等価です。
@ -46,8 +49,8 @@
* `OPTIONS /users`: エンド・ボイント `/users` に関してサポートされる動詞を示す。
* `OPTIONS /users/123`: エンド・ボイント `/users/123` に関してサポートされる動詞を示す。
`only` および `except` オプションを構成すると、それぞれ、どのアクションをサポートするか、また、どのアクションを無効にするかを明示的に指定することが出来ます。
例えば、
`only` および `except` オプションを構成すると、それぞれ、どのアクションをサポートするか、
また、どのアクションを無効にするかを明示的に指定することが出来ます。例えば、
```php
[
@ -75,10 +78,10 @@
この振舞いは [[yii\rest\UrlRule::pluralize]] を `false` に設定することで無効にすることが出来ます。
> Info: コントローラ ID の複数形化は [[yii\helpers\Inflector::pluralize()]] によって行われます。
このメソッドは特殊な複数形の規則を考慮します。
例えば、`box` という単語の複数形は `boxs` ではなく `boxes` になります。
このメソッドは特殊な複数形の規則を考慮します。例えば、`box` という単語の複数形は `boxs` ではなく `boxes` になります。
自動的な複数形化があなたの要求を満たさない場合は、[[yii\rest\UrlRule::controller]] プロパティを構成して、エンド・ボイント URL で使用される名前とコントローラ ID の対応を明示的に指定することも可能です。
自動的な複数形化があなたの要求を満たさない場合は、[[yii\rest\UrlRule::controller]] プロパティを構成して、
エンド・ボイント URL で使用される名前とコントローラ ID の対応を明示的に指定することも可能です。
例えば、次のコードはエンド・ボイント名 `u` をコントローラ ID `user` に割り当てます。
```php

33
docs/guide-ja/rest-versioning.md

@ -1,14 +1,12 @@
バージョン管理
==============
良い API は*バージョン管理* されています。
すなわち、一つのバージョンを絶え間なく変更するのではなく、変更と新機能は API の新しいバージョンにおいて実装されます。
クライアント・サイドとサーバ・サイドの両方のコードを完全に制御できるウェブ・アプリケーションとは違って、API はあなたの制御が及ばないクライアントによって使用されることを想定したものです。
このため、API の後方互換性 (BC) は、可能な限り保たれなければなりません。
BC を損なうかも知れない変更が必要な場合は、それを API の新しいバージョンにおいて導入し、バージョン番号を上げるべきです。
そうすれば、既存のクライアントは、API の古いけれども動作するバージョンを使い続けることが出来ますし、新しいまたはアップグレードされたクライアントは、新しい API バージョンで新しい機能を使うことが出来ます。
良い API は*バージョン管理* されています。すなわち、一つのバージョンを絶え間なく変更するのではなく、変更と新機能は API の新しいバージョンにおいて実装されます。
クライアント・サイドとサーバ・サイドの両方のコードを完全に制御できるウェブ・アプリケーションとは違って、API はあなたの制御が及ばないクライアントによって使用されることを想定したものです。このため、API の後方互換性 (BC) は、可能な限り保たれなければなりません。
BC を損なうかも知れない変更が必要な場合は、それを API の新しいバージョンにおいて導入し、バージョン番号を上げるべきです。そうすれば、既存のクライアントは、API の古いけれども動作するバージョンを使い続けることが出来ますし、新しいまたはアップグレードされたクライアントは、新しい API バージョンで新しい機能を使うことが出来ます。
> Tip: API のバージョン番号の設計に関する詳細情報は [Semantic Versioning](http://semver.org/) を参照してください。
> Tip: API のバージョン番号の設計に関する詳細情報は
[Semantic Versioning](http://semver.org/) を参照してください。
API のバージョン管理を実装する方法としてよく使われるのは、バージョン番号を API の URL に埋め込む方法です。
例えば、`http://example.com/v1/users` が API バージョン 1 の `/users` エンド・ボイントを指す、というものです。
@ -28,10 +26,12 @@ Accept: application/vnd.company.myapp-v1+json
* API 実装の各メジャー・バージョンを独立したモジュールに置き、モジュールの ID はメジャー・バージョン番号 (例えば `v1``v2`) とします。
当然ながら、API の URL はメジャー・バージョン番号を含むことになります。
* 各メジャー・バージョンの中では (従って対応するモジュールの中では) `Accept` HTTP リクエスト・ヘッダを使ってマイナー・バージョン番号を決定し、マイナー・バージョンに応じたレスポンスのための条件分岐コードを書きます。
* 各メジャー・バージョンの中では (従って対応するモジュールの中では) `Accept` HTTP リクエスト・ヘッダを使ってマイナー・バージョン番号を決定し、
マイナー・バージョンに応じたレスポンスのための条件分岐コードを書きます。
メジャー・バージョンを提供する各モジュールは、それぞれ、指定されたバージョンのためのリソースとコントローラのクラスを含んでいなければなりません。
コードの責任範囲をより良く分離するために、共通の基底のリソースとコントローラのクラスを保持して、それをバージョンごとの個別のモジュールでサブ・クラス化することが出来ます。
コードの責任範囲をより良く分離するために、共通の基底のリソースとコントローラのクラスを保持して、
それをバージョンごとの個別のモジュールでサブ・クラス化することが出来ます。
サブ・クラスの中で、`Model::fields()` のような具体的なコードを実装します。
あなたのコードを次のように編成することが出来ます。
@ -90,17 +90,22 @@ return [
];
```
上記のコードの結果として、`http://example.com/v1/users` はバージョン 1 のユーザ一覧を返し、`http://example.com/v2/users` はバージョン 2 のユーザ一覧を返すことになります。
上記のコードの結果として、`http://example.com/v1/users` はバージョン 1 のユーザ一覧を返し、
`http://example.com/v2/users` はバージョン 2 のユーザ一覧を返すことになります。
モジュール化のおかげで、異なるメジャー・バージョンのためのコードを綺麗に分離することが出来ます。
しかし、モジュール化しても、共通の基底クラスやその他の共有リソースを通じて、モジュール間でコードを再利用することは引き続いて可能です。
マイナー・バージョン番号を扱うためには、[[yii\filters\ContentNegotiator|contentNegotiator]] ビヘイビアによって提供されるコンテント・ネゴシエーションの機能を利用することが出来ます。
`contentNegotiator` ビヘイビアは、どのコンテント・タイプをサポートするかを決定するときに、[[yii\web\Response::acceptParams]] プロパティをセットします。
マイナー・バージョン番号を扱うためには、[[yii\filters\ContentNegotiator|contentNegotiator]]
ビヘイビアによって提供されるコンテント・ネゴシエーションの機能を利用することが出来ます。
`contentNegotiator` ビヘイビアは、どのコンテント・タイプをサポートするかを決定するときに、
[[yii\web\Response::acceptParams]] プロパティをセットします。
例えば、リクエストが HTTP ヘッダ `Accept: application/json; version=v1` を伴って送信された場合、コンテント・ネゴシエーションの後では、[[yii\web\Response::acceptParams]] に `['version' => 'v1']` という値が含まれています。
例えば、リクエストが HTTP ヘッダ `Accept: application/json; version=v1` を伴って送信された場合、
コンテント・ネゴシエーションの後では、[[yii\web\Response::acceptParams]] に `['version' => 'v1']` という値が含まれています。
`acceptParams` のバージョン情報に基づいて、アクション、リソース・クラス、シリアライザなどの個所で条件付きのコードを書いて、適切な機能を提供することが出来ます。
`acceptParams` のバージョン情報に基づいて、アクション、リソース・クラス、シリアライザなどの個所で条件付きのコードを書いて、
適切な機能を提供することが出来ます。
マイナー・バージョンは、定義上、後方互換性を保つことを要求するものですので、コードの中でバージョンチェックをする個所はそれほど多くないものと期待されます。
そうでない場合は、たいていは、新しいメジャー・バージョンを作成する必要がある、ということです。

Loading…
Cancel
Save