golang rpc

xuanbao · · 531 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>Hi, Ive been reading about golang rpc and I dont really understand it. I downloaded a talk on it this morning and just didnt understand what the speaker was talking about at all. </p> <p><a href="https://www.youtube.com/watch?v=KjI0OwdiABo&amp;t=4s">https://www.youtube.com/watch?v=KjI0OwdiABo&amp;t=4s</a></p> <p>can anyone tell me in what context id use this library and how it would be applied to the implementation of a rest api if at all. pardon my ignorance and thanks</p> <hr/>**评论:**<br/><br/>p7r: <pre><p>RPC is not REST. That&#39;s one of the things that&#39;s confusing you.</p> <p>Using raw RPC is considered a bit of a smell these days, most people would consider for these use cases gRPC. I recommend you take a read of <a href="https://grpc.io">https://grpc.io</a></p> <p>Now, add protobufs. <a href="https://developers.google.com/protocol-buffers/docs/overview">https://developers.google.com/protocol-buffers/docs/overview</a></p> <p>So, now you have an object representation being shared everywhere in a way that is very fast, and you can automatically generate client SDKs for. When you implement your server, you can generate the SDK and hand it to another team/developer and they&#39;re off to the races, with a ton of decisions made for you.</p> <p>Should you use it everywhere? No.</p> <p>But REST is not a golden goose, it has drawbacks, and when compared next to gRPC, you can see some occasions where you&#39;d choose one over the other or vice versa.</p></pre>natefinch: <pre><p>JSON RPC is a much easier learning curve, I&#39;d recommend starting there, and there&#39;s support for it in the stdlib.</p></pre>: <pre><p>[deleted]</p></pre>natefinch: <pre><p>note that the OP mentioned go RPC, not gRPC... different things. </p></pre>natefinch: <pre><p>OK, so RPC is effectively &#34;magic function calls that work across networks&#34;. That&#39;s what it stands for - Remote Procedure Calls. </p> <p>This is different than REST which is basically &#34;map URLs to resource types, and HTTP methods to CRUD operations&#34;. </p> <p>REST traditionally only functions on resources... &#34;Create this resource&#34; &#34;delete this resource&#34;. Which is all fine and good until you want to do something that&#39;s not just CRUD... like &#34;transfer $500 from account 1 to account 2&#34;. Now what do you do? You could easily make a URL that lets you do that, but it&#39;s pretty ugly, and goes against the REST ethos. Some people will say you can make a &#34;Transaction&#34; objects that debits from one account and adds to another... but then you&#39;re getting into ugly &#34;let&#39;s make objects for things that aren&#39;t actually objects&#34;.</p> <p>What you want is function calls. Like Transfer(acct1 string, acct2 string, money int)</p> <p>RPC lets you do that. RPC is defined as just functions. The functions take values that get serialized to some wire format (JSON GOB protobuf, whatever), and sent over the wire to the server, which deserializes them, runs the function, and serializes a return value.</p> <p>This is honestly how a lot of people use REST anyway, it just cuts out the middle man of poor mapping of URLs and HTTP methods to things that go beyond that scope.</p> <p>The main drawback of RPC, and the main draw of REST, is that with REST you have URLs you can hit with a browser for easy testing. RPC... not so much. You need a real client programmed in some language. Depending on your use cases, one or the other might be better... though in my opinion, REST has run its course, and should basically never be used anymore. No one has a pure CRUD website/server, so don&#39;t use a pure CRUD API technology like REST.</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

531 次点击  
加入收藏 微博
0 回复
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传