From 3df19b2e4f3c020a20962960c92808404b9811a3 Mon Sep 17 00:00:00 2001 From: bali <40886141+n-ae@users.noreply.github.com> Date: Sat, 29 Jun 2024 03:09:29 +0300 Subject: [PATCH] Fix links to Debunking the myths of RPC and REST (#855) --- README-ja.md | 4 ++-- README-zh-Hans.md | 4 ++-- README-zh-TW.md | 4 ++-- README.md | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/README-ja.md b/README-ja.md index 0f003b2d4ab..c5e58a009e6 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1450,7 +1450,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは * RPCクライアントとはサービス実装により厳密に左右されることになります。 * 新しいオペレーション、使用例があるたびに新しくAPIが定義されなければなりません。 * RPCをデバッグするのは難しい可能性があります。 -* 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。 +* 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。 ### Representational state transfer (REST) @@ -1502,7 +1502,7 @@ RESTはデータを公開することに焦点を当てています。クライ * [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) * [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186) * [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) -* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) +* [Debunking the myths of RPC and REST](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) * [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) * [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) * [Thrift](https://code.facebook.com/posts/1468950976659943/) diff --git a/README-zh-Hans.md b/README-zh-Hans.md index 368f588ad78..65dbe23cc00 100644 --- a/README-zh-Hans.md +++ b/README-zh-Hans.md @@ -1462,7 +1462,7 @@ RPC 专注于暴露方法。RPC 通常用于处理内部通讯的性能问题， * RPC 客户端与服务实现捆绑地很紧密。 * 一个新的 API 必须在每一个操作或者用例中定义。 * RPC 很难调试。 -* 你可能没办法很方便的去修改现有的技术。举个例子，如果你希望在 [Squid](http://www.squid-cache.org/) 这样的缓存服务器上确保 [RPC 被正确缓存](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)的话可能需要一些额外的努力了。 +* 你可能没办法很方便的去修改现有的技术。举个例子，如果你希望在 [Squid](http://www.squid-cache.org/) 这样的缓存服务器上确保 [RPC 被正确缓存](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)的话可能需要一些额外的努力了。 ### 表述性状态转移（REST） @@ -1514,7 +1514,7 @@ REST 关注于暴露数据。它减少了客户端／服务端的耦合程度， * [你真的知道你为什么更喜欢 REST 而不是 RPC 吗](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) * [什么时候 RPC 比 REST 更合适？](http://programmers.stackexchange.com/a/181186) * [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) -* [揭开 RPC 和 REST 的神秘面纱](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) +* [揭开 RPC 和 REST 的神秘面纱](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) * [使用 REST 的缺点是什么](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) * [破解系统设计面试](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) * [Thrift](https://code.facebook.com/posts/1468950976659943/) diff --git a/README-zh-TW.md b/README-zh-TW.md index d805e7e00c9..70449a75694 100644 --- a/README-zh-TW.md +++ b/README-zh-TW.md @@ -1451,7 +1451,7 @@ RPC 專注於揭露行為，它通常用來處理內部通訊的效能問題， * RPC 的客戶端會變得和伺服器的實作綁得更死 * 一個新的 API 必須在每個操作或使用案例中進行定義 * RPC 很難抓錯誤 -* 你很難方便的修改現有的技術，舉例來說，如果你希望在 [Squid](http://www.squid-cache.org/) 這樣的快取伺服器上確保 [RPC 呼叫被正確的快取](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)，你可以需要多費額外的努力了。 +* 你很難方便的修改現有的技術，舉例來說，如果你希望在 [Squid](http://www.squid-cache.org/) 這樣的快取伺服器上確保 [RPC 呼叫被正確的快取](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)，你可以需要多費額外的努力了。 ### 具象狀態轉移 (REST) @@ -1503,7 +1503,7 @@ REST 關注於揭露資料，減少客戶端/伺服器之間耦合的程度， * [你真的知道為什麼你更喜歡 REST 而不是 RPC 嗎？](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) * [什麼時候 RPC 比 REST 更適合](http://programmers.stackexchange.com/a/181186) * [REST 和 JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) -* [揭開 RPC 和 REST 的神秘面紗](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) +* [揭開 RPC 和 REST 的神秘面紗](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) * [使用 REST 的缺點](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) * [破解系統設計面試](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) * [Thrift](https://code.facebook.com/posts/1468950976659943/) diff --git a/README.md b/README.md index 95be990d3cb..f2285f36461 100644 --- a/README.md +++ b/README.md @@ -1499,7 +1499,7 @@ HTTP APIs following **REST** tend to be used more often for public APIs. * 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/). +* 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](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) on caching servers such as [Squid](http://www.squid-cache.org/). ### Representational state transfer (REST) @@ -1551,7 +1551,7 @@ REST is focused on exposing data. It minimizes the coupling between client/serv * [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) * [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186) * [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) -* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) +* [Debunking the myths of RPC and REST](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) * [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) * [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) * [Thrift](https://code.facebook.com/posts/1468950976659943/)