<p>Hello Redditors / Gophers,</p>
<p>I'm (a beginner) trying to develop an interactive web page (displaying a dashboard) with HTML and JavaScript at the client side and Go at the server side (the go server calls multiple APIs and manages the data). I'm doing it this way because I had problems with CORS when I only used JS to directly call the APIs from which I need to get the data.</p>
<p>I'd like to know on the server side if the best thing (maybe the only thing, I don't know) to do is to build an API ? Or is there other options ? Is there any references / examples I should take a look at ?</p>
<p>Thanks in advance (and sorry if my question is trivial).</p>
<hr/>**评论：**<br/><br/>dAnjou: <pre><blockquote>
<p>I'd like to know on the server side if the best thing (maybe the only thing, I don't know) to do is to build an API ?</p>
</blockquote>
<p>The term API is soooo overloaded these days ...</p>
<p>I suppose you're referring to a RESTful API. And whether that's a good idea is pretty much a "business" decision more than anything else. It depends on whether you're planning to serve different kinds of client applications and whether you want partners or other external systems to interact with your service. If not a RESTful API is of questionable benefit because in addition to implementing the API itself you have to implement some kind of workflow on top of it. But maybe that's not such a big issue with a dashboard type of thing.</p></pre>decapre555: <pre><p>Thanks for your answer dAnjou. Yes, it would be a RESTful API. It would only serve the dashboard in my case. Is there another kind of API that would be more appropriate ?</p></pre>dAnjou: <pre><p>Look, it's just HTTP. You can call the endpoints whatever you want, like <code>/gimmethatstuff</code> and <code>/gimmethatotherstuff</code>.</p>
<p>You won't get it perfect the first time anyway. So just go ahead and get your hands dirty :)</p>
<p><strong>UPDATE</strong> Of course you can make it your goal to write a proper RESTful API. That's reasonable. Then the whole thing will probably take longer but what's the rush, right? As long as you learn something.</p></pre>decapre555: <pre><p>I know how a RESTful API works, I've already developed a small one (sorry, I should have precised it earlier). I was wondering if there's another type of service that I can use / develop and that would be more appropriate in my situation (but yes, in my case, performance isn't very important as long as it doesn't take too long to load and display all the data) ? Thanks !</p></pre>dAnjou: <pre><p>Ah.</p>
<p>Imagine you have services <em>Foo</em> and <em>Bar</em>. Foo's API exposes data about cats and it's latest API version is 3, so their endpoints might look like this: <code>/v3/cats/<ID></code>. Similarly, Bar's API is on version 1 and exposes data about locations like this: <code>/v1/loc/<X>/<Y>/</code>. Then you could expose the endpoints <code>/foo/</code> and <code>/bar/</code>. Requests to these endpoints would look like this: <code>/foo/v3/cats/<ID></code> and <code>/bar/v1/loc/<X>/<Y>/</code>. You can configure your webserver to simply proxy those requests to the 3rd party APIs by dropping the prefix.</p>
<p>Just a thought experiment. No idea whether it's any good. If it is however, you wouldn't even need any application code.</p></pre>decapre555: <pre><p>Thanks for your answer, that's interesting. I'll dig into that.</p></pre>
