Correct mistranslation

- The original translation doesn't make sense.
2019-10-21 15:19:53 +09:00 · 2019-10-21 15:19:53 +09:00 · ba02ebee2c
parent e7c2e0e20a
commit ba02ebee2c
1 changed files with 1 additions and 1 deletions
--- a/README-ja.md
+++ b/README-ja.md
@ -1477,7 +1477,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは
 #### 欠点: REST

 * RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。
-* RESTは少数の動詞に依存しています(GET、POST、PUT、DELETE、そして PATCH) が時には使いたい事例に合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。
+* 一般的に、RESTでは限られたHTTP動詞のみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。
 * ネストされたヒエラルキーの中にあるリソースをとってくるのはシングルビューを描画するのにクライアントとサーバー間で数回やりとりしなければなりません。例として、ブログエントリーのコンテンツとそれに対するコメントを表示する場合などです。様々なネットワーク環境で動作する可能性が考えられるモバイルアプリケーションにおいてはこのような複数のやり取りは好ましくありません。
 * 時が経つにつれて、APIレスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシーも拡大することになります。