mirrors
/
system-design-primer
mirror of https://github.com/donnemartin/system-design-primer.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update README-ja.md 

Change "動詞" to "メソッド" according to RFC
pull/331/head
SATO Yusuke 2020-02-08 18:03:23 +09:00
parent 5601b4b400
commit a8354e9040
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README-ja.md
View File

@ -1330,9 +1330,9 @@ def set_user(user_id, values):
HTTPはリクエスト・レスポンス型のプロトコルです。クライアントがリクエストを投げると、サーバーはそのリクエストに対応するコンテンツと完了ステータスをレスポンスとして返します。HTTPは自己完結したプロトコルです。リクエストやレスポンスが数多くのサーバーやルーターを通過し、その間にロードバランシング、キャッシュ、暗号化、圧縮などが行われていても、問題なく動くようにできています。
基本的なHTTPリクエストはHTTP動詞(メソッド)とリソース(エンドポイント)で成り立っています。よく使われるHTTP動詞としては以下のものが挙げられます:
基本的なHTTPリクエストはHTTPメソッド(動詞)とリソース(エンドポイント)で成り立っています。よく使われるHTTPメソッドとしては以下のものが挙げられます:
| 動詞 | 詳細 | 冪等性* | セーフ | キャッシュできるか |
| メソッド | 詳細 | 冪等性* | セーフ | キャッシュできるか |
|---|---|---|---|---|
| GET | リソースを読み取る | Yes | Yes | Yes |
| POST | リソースを作成する、またはデータを処理するプロセスをトリガーする | No | No | Yes レスポンスが新しい情報を含む場合 |
@ -1459,7 +1459,7 @@ RESTはアーキテクチャスタイルの一つで、クライアント・サ
RESTful なインターフェースには次の四つの特徴があります:
* **リソース(HTTPにおけるURI)によって識別される** - どのオペレーションであっても同じURIを使うこと。
* **表現(HTTPにおける動詞)によって変化する** - 動詞、ヘッダー、ボディを使うこと。
* **表現(HTTPにおけるメソッド)によって変化する** - メソッド、ヘッダー、ボディを使うこと。
* **自己説明的なエラーメッセージ (HTTPにおけるステータスレスポンス)** - ステータスコードを使うこと。車輪の再発明はしないこと。
* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTPにおけるHTMLインタフェース)** - Webサービスがブラウザから完全にアクセスできること。
@ -1472,12 +1472,12 @@ PUT /someresources/anId
{"anotherdata": "another value"}
```
RESTはデータを公開することに焦点を当てています。RESTではクライアントとサーバーの結合度を最小にでき、公開APIなどによく用いられます。RESTでは、リソースの公開にはURI、リソースの[表現にはHTTPヘッダー](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、アクションにはHTTP動詞（GET, POST, PUT, DELETE, PATCH）といったように、そのそれぞれに対してより一般的で統一された方法を用います。RESTはステートレスなので、水平スケーリングやパーティショニングに最適です。
RESTはデータを公開することに焦点を当てています。RESTではクライアントとサーバーの結合度を最小にでき、公開APIなどによく用いられます。RESTでは、リソースの公開にはURI、リソースの[表現にはHTTPヘッダー](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、アクションにはHTTPメソッド（GET, POST, PUT, DELETE, PATCH）といったように、そのそれぞれに対してより一般的で統一された方法を用います。RESTはステートレスなので、水平スケーリングやパーティショニングに最適です。
#### 欠点: REST
* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。
* 一般的に、RESTでは限られたHTTP動詞のみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。
* 一般的に、RESTでは限られたHTTPメソッドのみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらのメソッドには綺麗にはフィットしません。
* 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。
* 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。