REST API Skeleton, Middleware library

<h1><a href="https://www.github.com/kressin/skeleton">skeleton</a></h1> <h1><a href="https://www.github.com/kressin/middleware">middleware</a></h1> <p> <br/> I&#39;m using a superset of the former and the latter as is in my startup. Dogfooding my work^{^}<br/>  <br/> Both are still under active development, but I think they are both good starting points for newer Gophers like myself.<br/>   </p> <h1>pkg skeleton</h1> <ul> <li>purely REST api </li> <li>net/context - moving away from global vars, greater concurrency than global contexts like gorilla/mux<br/></li> <li>slice of prepared statements added to context - fix to <a href="https://vividcortex.com/blog/2014/11/19/analyzing-prepared-statement-performance-with-vividcortex/">common mistake new Gophers make</a><br/> -- not sure the best way to do stmt.Close() here. defer stmt.Close() immediately kills everything</li> <li>JWT for auth -- needs a better way to handle logout to invalidate tokens (only way I can think of is a database -not fully REST)<br/> -- Failing to handle token invalidation on server-side means that an attack vector is open, for the remaining duration of user A&#39;s token, where user A logs out, and user B, on the same machine (or remote with super privileges on user A&#39;s machine), hacks into the RAM, and is able to use and refresh user A&#39;s session a la Firesheep with cookies. Normal use case, returning back an empty Authorization header will suffice to logout<br/></li> <li>Logger wrapping http.ResponseWriter-- aware of http status codes<br/>  <br/></li> </ul> <h1>pkg middleware</h1> <ul> <li>alice style chaining for custom type ContextHandler interface -- ServeHTTPC(context.Context, http.ResponseWriter, *http.Request)<br/></li> <li>httprouter routing<br/></li> <li>gzipper for each response<br/></li> <li>basic panic-recovery handler<br/></li> <li>SQL statement sanitizer if not using prepared statements -- as a safer alternative to fmt.Sprintf</li> <li>private key signing/public key validating<br/></li> <li>fixes <a href="https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/">this vulnerability</a> using pkg author&#39;s recommendations<br/></li> <li>refreshes token per request<br/> -- when logging in, registering, or changing user permissions need to do manually, like in pkg skeleton<br/>  <br/></li> </ul> <p>Please feel free to edit, criticize, use as you wish. Seeing as I&#39;m using this, I would love feedback.<br/>  <br/> They are both MIT licensed. Use them as if they were your own code.<br/>  <br/> Updated repository + readme to help users get started per requests.</p> <hr/>**评论：**<br/><br/>lumost: <pre><p>looks pretty interesting, although it&#39;s hard to tell what the benefits are without an example.</p></pre>Emperor_Earth: <pre><p>skeleton is the working example of a REST API server. The link is at the top. </p> <p>Toy and tinker with either package as you wish to extend on that. </p> <p>A few starter db statements, routes, custom handlers, etc, are already included to give you a head start.</p></pre>anonymizedconvo: <pre><p>um... first line is the link... dude</p></pre>daveddev: <pre><p>Users should not need to make the chain compatible with http.Handler. Also, handler wrapping should not be bound to routing. Middleware is already an abused term with Go web-devs. More so by being stretched to include the concept of a framework. I suggest calling this a framework (which includes handler wrapping).</p> <p>For a more modular solution, please have a look at my own implementation of handler wrapping: <a href="https://github.com/codemodus/chain" rel="nofollow">https://github.com/codemodus/chain</a></p> <p>Edit - Replaced rhetoric with direct statement and added a bit more.</p> <p>Edited again to add: After a bit more thought, I think that if you called it a framework, I wouldn&#39;t have any concern regarding http.Handler compatibility or how tightly bound your components are. Though, I tend to think web frameworks in Go are bad news.</p></pre>Emperor_Earth: <pre><p>Calling it a framework vs library:<br/> I&#39;m not sure on the semantics myself, perhaps you&#39;re right.<br/> middleware is a set of tools that you can pick and choose<br/> http.Handler compatible functions are available, as are middleware.ContextHandler functions<br/>  <br/> skeleton is intended as a starting point using some of middleware. fork and fiddle to go<br/>  <br/> http.Handler compatibility &amp; context:<br/> By uncommenting <a href="https://github.com/kressin/middleware/blob/master/type.go#L28-L30" rel="nofollow">3 lines</a>, you can have http.Handler compatibility. You will, however, lose context. Originally, many Go devs espoused <a href="http://www.gorillatoolkit.org/pkg/context" rel="nofollow">gorilla/context</a>. They have since referred users to <a href="http://godoc.org/golang.org/x/net/context" rel="nofollow">net/context</a>, their own solution to context.<br/>  <br/> The issue with context is 4 solutions:<br/> 1) Re-parse/re-call database every route&#39;s handler<br/> + don&#39;t break http.Handler compatibility<br/> - very verbose/error prone<br/> 2) Use gorilla/context<br/> + don&#39;t break http.Handler compatibility<br/> + very simple solution, especially if using the excellent gorilla/mux as your muxer<br/> - global context variable<br/> - mutex/locks<br/> 3) Pass context as a per-request parameter (google&#39;s own solution: net/context, Goji) <br/> + non-global context<br/> + safe for concurrent-access/go-routines<br/> - break http.Handler compatibility<br/> 4) structs with method middleware (gocraft)<br/> + no type assertions<br/> - bigger change from accepted practices<br/>  <br/> Your library mixes #3 &amp; #4 to provide a subset of mine&#39;s features. In syntactic sugar for chaining, we all owe our inspiration to <a href="https://github.com/justinas/alice" rel="nofollow">justinas/alice</a>. It is definitely more mature than mine! I still need to write tests, among other things. (I&#39;ll probably move config to a read-in file)</p></pre>daveddev: <pre><p>Middleware is a misused term: Taken from <a href="http://en.wikipedia.org/wiki/Middleware" rel="nofollow">http://en.wikipedia.org/wiki/Middleware</a> - &#34;Middleware is the software that connects software components or enterprise applications. Middleware is the software layer that lies between the operating system and the applications on each side of a distributed computer network.&#34;</p> <p>Yes, handler wrapping (or chaining, if you&#39;d like), is one part of your offering. Yes, that is the part my chain package addresses. I have other packages which address other needs, and, for the most part, have my handler funcs within my applications due to the distinct lack of orthogonality involved. And while alice was one of the first on the scene (I&#39;ve used it quite a bit), it&#39;s just nested function management, a simple concept, and often unnecessary. Solving only a subset of your framework&#39;s features is a plus. I hope that the community will mature to see such frameworks fade away.</p> <p>&#34;By uncommenting 3 lines...&#34; No, that&#39;s poor design. Users should not forfeit using context within their chain to accommodate other handlers, or muxes which are not bound to your types. At first, I asked about http.Handler compatibility rhetorically (the solution is simple) because I felt it would expose a misunderstanding of what you&#39;re delivering, so it makes sense that your suggestion is from an all or nothing sort of mindset. Here is a way to adapt:</p> <pre><code>func wrapMiddleware(n middleware.ContextHandler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { n.ServeHTTPC(context.Background(), w, r) }) } </code></pre> <p>It&#39;s also strange to see the use of copy in Append instead of the append builtin.</p> <p>Break apart your framework into useful libraries and improve their capabilities for their specific purposes. For the fun of it, I ran some benchmarks which did not turn out to be noteworthy, but here you go:</p> <pre><code>BenchmarkCMChain10 30000 55.66 μs/op 3491 B/op 54 allocs/op BenchmarkXNest10 30000 55.55 μs/op 3486 B/op 54 allocs/op BenchmarkKressin10 30000 55.84 μs/op 3484 B/op 54 allocs/op </code></pre> <p><a href="https://gist.github.com/daved/6566099ba472c81fc18a" rel="nofollow">https://gist.github.com/daved/6566099ba472c81fc18a</a></p></pre>autowikibot: <pre><h5> </h5> <h6> </h6> <h4> </h4> <p><a href="https://en.wikipedia.org/wiki/Middleware" rel="nofollow"><strong>Middleware</strong></a>: <a href="#sfw" rel="nofollow"></a> </p> <hr/> <blockquote> <p><strong>Middleware</strong> is a computer software that provides services to <a href="https://en.wikipedia.org/wiki/Software_application" rel="nofollow">software applications</a> beyond those available from the <a href="https://en.wikipedia.org/wiki/Operating_system" rel="nofollow">operating system</a>. It can be described as &#34;software glue&#34;. Middleware makes it easier for <a href="https://en.wikipedia.org/wiki/Software_developer" rel="nofollow">software developers</a> to perform communication and <a href="https://en.wikipedia.org/wiki/Input/output" rel="nofollow">input/output</a>, so they can focus on the specific purpose of their application. Middleware is the software that connects software components or enterprise applications. Middleware is the software layer that lies between the operating system and the applications on each side of a distributed computer network. Typically, it supports complex, distributed business software applications.</p> <h1></h1> <p><a href="https://i.imgur.com/DOSNa7e.png" rel="nofollow"><strong>Image</strong></a> <a href="https://commons.wikimedia.org/wiki/File:Linux_kernel_and_gaming_input-output_latency.svg" rel="nofollow">ⁱ</a> - <em>Anything between the kernel and user applications is considered middleware. Functionality such as gesture recognition or speech recognition is usually processed by some middleware, and the results are transmitted to user applications. [citation needed]</em></p> </blockquote> <hr/> <p>^Interesting: <a href="https://en.wikipedia.org/wiki/Game_engine" rel="nofollow">^Game ^engine</a> ^| <a href="https://en.wikipedia.org/wiki/Middleware_(distributed_applications)" rel="nofollow">^Middleware ^(distributed ^{applications)}</a> ^| <a href="https://en.wikipedia.org/wiki/Oracle_Fusion_Middleware" rel="nofollow">^Oracle ^Fusion ^Middleware</a> ^| <a href="https://en.wikipedia.org/wiki/List_of_game_middleware" rel="nofollow">^List ^of ^game ^middleware</a> </p> <p>^Parent ^commenter ^can <a href="/message/compose?to=autowikibot&amp;subject=AutoWikibot%20NSFW%20toggle&amp;message=%2Btoggle-nsfw+cs37lm1" rel="nofollow">^toggle ^NSFW</a> ^{or<a href="#or" rel="nofollow"></a>} <a href="/message/compose?to=autowikibot&amp;subject=AutoWikibot%20Deletion&amp;message=%2Bdelete+cs37lm1" rel="nofollow">^delete</a>^. ^Will ^also ^delete ^on ^comment ^score ^of ^-1 ^or ^less. ^| <a href="http://www.np.reddit.com/r/autowikibot/wiki/index" rel="nofollow">^FAQs</a> ^| <a href="http://www.np.reddit.com/r/autowikibot/comments/1x013o/for_moderators_switches_commands_and_css/" rel="nofollow">^Mods</a> ^| <a href="http://www.np.reddit.com/r/autowikibot/comments/1ux484/ask_wikibot/" rel="nofollow">^Magic ^Words</a></p></pre>