Hi Julia users, I'm planning to implement HTTP/2 support for Julia (and hopefully as a GSoC project!), extending the HTTPServer.jl and Requests.jl library. I need to make a design decision about whether I should put compatibility first with existing APIs, or I should design a new unified API. If you use or plan to use those libraries with HTTP/2 support, I would really appreciate it if you can share your opinions.
My current purposed API design approach is to create a new, unified API that can handle both HTTP/1.1 and HTTP/2. The API works by "disabling" certain functions and options if it is running in HTTP/1.1 mode. This, in my opinion, would benefit for the long run, because users that adopt this API can switch easily between HTTP/1.1 and HTTP/2. It also makes maintaining those libraries a little bit easier (we only need to maintain one API rather than two). A Python implementation of HTTP/2 called Hyper (https://hyper.readthedocs.org/) adopts a similar approach. However, in this approach, you may need to modify your codes to "upgrade" to HTTP/2. Another approach is to put compatibility first, so if you are an existing HTTPServer.jl or Requests.jl user, you would simply change a config option to "upgrade" to HTTP/2. This is not a "ugly" approach because Julia supports multiple return values. Those additional information of HTTP/2 can be set in those return values or in optional parameters. A NodeJS implementation of HTTP/2 called Node-http2 adopts a similar approach. So what's your opinion? -- Wei
