TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Do You Prefer REST or RPC Style APIs?

6 点作者 gauravphoenix超过 5 年前
Personally I prefer to expose REST APIs for the external (Internet) facing services for simplicity. For internal APIs I prefer gRPC for performance reasons. The real question is that if there are no technical limitations (HTTP 1.1 vs 2 etc, bi-directional and communication etc), which style of API would you prefer and why?

3 条评论

brillout超过 5 年前
For internal APIs I&#x27;d recommend RPC and REST&#x2F;GraphQL to create an API consumed by third parties.<p>Wildcard&#x27;s readme elaborates more on RPC vs REST: <a href="https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api</a><p>(Wildcard is RPC implementation for Node.js and the browser.)
derricgilling超过 5 年前
I prefer REST especially for public&#x2F;external APIs. It&#x27;s more empathetic towards third party developers who may not be as intimate with your API as your internal team. For example, much easier to reason a few well-understood entities like items, users, and orders if I was building an e-commerce API then a list of RPC operations. I would add GraphQL can also be easier to understand as long as the entity relations make sense. Lot&#x27;s of exciting stuff happening in the GraphQL world but it does have disadvantages also.
em10fan超过 5 年前
That depends, do you consider SOAP to fall into the latter category?<p>If so, no.