golang rpc

<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>