From 6e1f03e9590f1f9668d7d334e2281dd56a41cacd Mon Sep 17 00:00:00 2001 From: tsukukobaan Date: Sat, 21 Oct 2017 21:05:17 +0900 Subject: [PATCH] translation_ja REST --- README-jp.md | 82 ++++++++++++++++++++++++++-------------------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/README-jp.md b/README-jp.md index 1a973bdc..af41a046 100644 --- a/README-jp.md +++ b/README-jp.md @@ -1411,16 +1411,16 @@ TCPよりもUDPを使うのは: Source: Crack the system design interview

-In an RPC, a client causes a procedure to execute on a different address space, usually a remote server. The procedure is coded as if it were a local procedure call, abstracting away the details of how to communicate with the server from the client program. Remote calls are usually slower and less reliable than local calls so it is helpful to distinguish RPC calls from local calls. Popular RPC frameworks include [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), and [Avro](https://avro.apache.org/docs/current/). +RPCではクライアントがリモートサーバーなどの異なるアドレス空間でプロシージャーが処理されるようにします。プロシージャーはローカルでのコールのように、クライアントからサーバーにどのように通信するかという詳細を省いた状態でコードが書かれます。リモートのコールは普通、ローカルのコールよりも遅く、信頼性に欠けるため、RPCコールをローカルコールと区別させておくことが好ましいでしょう。人気のRPCフレームワークは以下です。[Protobuf](https://developers.google.com/protocol-buffers/)、 [Thrift](https://thrift.apache.org/)、[Avro](https://avro.apache.org/docs/current/) -RPC is a request-response protocol: +RPC は リクエストレスポンスプロトコル: -* **Client program** - Calls the client stub procedure. The parameters are pushed onto the stack like a local procedure call. -* **Client stub procedure** - Marshals (packs) procedure id and arguments into a request message. -* **Client communication module** - OS sends the message from the client to the server. -* **Server communication module** - OS passes the incoming packets to the server stub procedure. -* **Server stub procedure** - Unmarshalls the results, calls the server procedure matching the procedure id and passes the given arguments. -* The server response repeats the steps above in reverse order. +* **クライアントプログラム** - クライアントスタブプロシージャーを呼び出します。パラメータはローカルでのプロシージャーコールのようにスタックへとプッシュされていきます。 +* **クライアントスタブプロシージャー** - プロシージャIDとアーギュメントをパックしてリクエストメッセージにします。 +* **クライアント通信モジュール** - OSがクライアントからサーバーへとメッセージを送ります。 +* **サーバー通信モジュール** - OSが受け取ったパケットをサーバースタブプロシージャーに受け渡します。 +* **サーバースタブプロシージャー** - 結果を展開し、プロシージャーIDにマッチするサーバープロシージャーを呼び出し、結果を返します。 +* サーバーレスポンスは上記のステップを逆順で繰り返します。 Sample RPC calls: @@ -1434,36 +1434,36 @@ POST /anotheroperation } ``` -RPC is focused on exposing behaviors. RPCs are often used for performance reasons with internal communications, as you can hand-craft native calls to better fit your use cases. +RPCは振る舞いを公開することに焦点を当てています。RPCは内部通信パフォーマンスを理由として使われることが多いです。というのも、使用する状況に合わせてネーティブコールを自作することができるからです。 -Choose a native library (aka SDK) when: +ネイティブライブラリー (aka SDK) を呼ぶのは以下の時: -* You know your target platform. -* You want to control how your "logic" is accessed. -* You want to control how error control happens off your library. -* Performance and end user experience is your primary concern. +* ターゲットのプラットフォームを知っている時 +* ロジックがどのようにアクセスされるのかを管理したいとき +* ライブラリー外でエラーがどのようにコントロールされるかを管理したい時 +* パフォーマンスとエンドユーザーエクスペリエンスが最優先の時 -HTTP APIs following **REST** tend to be used more often for public APIs. +**REST** プロトコルに従うHTTP APIはパブリックAPIにおいてよく用いられます。tend to be used more often for public APIs. -#### Disadvantage(s): RPC +#### 欠点: RPC -* RPC clients become tightly coupled to the service implementation. -* A new API must be defined for every new operation or use case. -* It can be difficult to debug RPC. -* You might not be able to leverage existing technologies out of the box. For example, it might require additional effort to ensure [RPC calls are properly cached](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) on caching servers such as [Squid](http://www.squid-cache.org/). +* RPCクラインとはサービス実装により厳密に左右されることになります。 +* 新しいオペレーション、使用例があるたびに新しくAPIが定義されなければなりません。 +* RPCをデバッグするのは難しい可能性があります。 +* 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。 ### Representational state transfer (REST) -REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by the server. The server provides a representation of resources and actions that can either manipulate or get a new representation of resources. All communication must be stateless and cacheable. +RESTは、クライアントがサーバーによってマネージされるリソースに対して処理を行うクライアント・サーバーモデルを支持するアーキテキチャスタイルです。サーバーは操作できるもしくは新しいリソースれプレゼンテーションを受け取ることができるようなリソースやアクションのレプレゼンテーションを提供します。すべての通信はステートレスでキャッシュ可能でなければなりません。 -There are four qualities of a RESTful interface: +RESTful なインターフェースには次の四つの特徴があります: -* **Identify resources (URI in HTTP)** - use the same URI regardless of any operation. -* **Change with representations (Verbs in HTTP)** - use verbs, headers, and body. -* **Self-descriptive error message (status response in HTTP)** - Use status codes, don't reinvent the wheel. -* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - your web service should be fully accessible in a browser. +* **特徴的なリソース (URI in HTTP)** - どのオペレーションであっても同じURIを使う。 +* **HTTP動詞によって変わる (Verbs in HTTP)** - 動詞、ヘッダー、ボディを使う +* **自己説明的なエラーメッセージ (status response in HTTP)** - ステータスコードを使い、新しく作ったりしないこと。 +* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - 自分のwebサービスがブラウザで完全にアクセスできること。 -Sample REST calls: +サンプル REST コール: ``` GET /someresources/anId @@ -1472,26 +1472,26 @@ PUT /someresources/anId {"anotherdata": "another value"} ``` -REST is focused on exposing data. It minimizes the coupling between client/server and is often used for public HTTP APIs. REST uses a more generic and uniform method of exposing resources through URIs, [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), and actions through verbs such as GET, POST, PUT, DELETE, and PATCH. Being stateless, REST is great for horizontal scaling and partitioning. +RESTはデータを公開することに焦点を当てています。クライアントとサーバーのカップリングを最小限にするもので、パブリックAPIなどによく用いられます。RESTはURI、 [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、そして、GET、POST、PUT、 DELETE、PATCHなどのHTTP動詞等のよりジェネリックで統一されたメソッドを用います。ステートレスであるのでRESTは水平スケーリングやパーティショニングに最適です。 -#### Disadvantage(s): REST +#### 欠点: REST -* With REST being focused on exposing data, it might not be a good fit if resources are not naturally organized or accessed in a simple hierarchy. For example, returning all updated records from the past hour matching a particular set of events is not easily expressed as a path. With REST, it is likely to be implemented with a combination of URI path, query parameters, and possibly the request body. -* REST typically relies on a few verbs (GET, POST, PUT, DELETE, and PATCH) which sometimes doesn't fit your use case. For example, moving expired documents to the archive folder might not cleanly fit within these verbs. -* Fetching complicated resources with nested hierarchies requires multiple round trips between the client and server to render single views, e.g. fetching content of a blog entry and the comments on that entry. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable. -* Over time, more fields might be added to an API response and older clients will receive all new data fields, even those that they do not need, as a result, it bloats the payload size and leads to larger latencies. +* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、とあるイベントのセットにマッチするすべての更新情報を返すと言った処理は簡単にはパスで表現することができません。RESTでは、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどによって実装されることが多いでしょう。 +* RESTは少数の動詞に依存しています(GET、POST、PUT、DELETE、そして PATCH) が時には使いたい事例に合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。 +* ネストされたヒエラルキーの中にあるリソースをとってくるのはシングルビューを描画するのにクライアントとサーバー間で数回やりとりしなければなりません。例として、ブログエントリーのコンテンツとそれに対するコメントを表示する場合などです。様々なネットワーク環境で動作する可能性が考えられるモバイルアプリケーションにおいてはこのような複数のやり取りは好ましくありません。 +* 時が経つにつれて、APIレスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシも拡大することになります。 -### RPC and REST calls comparison +### RPCとREST比較 | Operation | RPC | REST | |---|---|---| -| Signup | **POST** /signup | **POST** /persons | -| Resign | **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 | -| Read a person | **GET** /readPerson?personid=1234 | **GET** /persons/1234 | -| Read a person’s items list | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items | -| Add an item to a person’s items | **POST** /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | **POST** /persons/1234/items
{
"itemid": "456"
} | -| Update an item | **POST** /modifyItem
{
"itemid": "456";
"key": "value"
} | **PUT** /items/456
{
"key": "value"
} | -| Delete an item | **POST** /removeItem
{
"itemid": "456"
} | **DELETE** /items/456 | +| サインアップ | **POST** /signup | **POST** /persons | +| リザイン | **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 | +| Person読み込み | **GET** /readPerson?personid=1234 | **GET** /persons/1234 | +| Personのアイテムリスト読み込み | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items | +| Personのアイテムへのアイテム追加 | **POST** /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | **POST** /persons/1234/items
{
"itemid": "456"
} | +| アイテム更新 | **POST** /modifyItem
{
"itemid": "456";
"key": "value"
} | **PUT** /items/456
{
"key": "value"
} | +| アイテム削除 | **POST** /removeItem
{
"itemid": "456"
} | **DELETE** /items/456 |

Source: Do you really know why you prefer REST over RPC