英文:
Can a Golang SDK expose a REST API via the service intgrating the SDK
问题
我是新手,对Golang编程不太了解,想知道在Golang中是否可以实现以下功能:
- 我创建一个Golang SDK,暴露一个API(/golang-sdk/test-api POST)。
- 一些项目将我的SDK作为依赖项。
- 该服务会暴露API(/golang-sdk/test-api)。
谢谢!如果可能的话,提供任何关于这方面的POC或文档将非常有帮助。
英文:
I am new to Golang programming and was wondering if this is possible in golang.
- I create an SDK in golang that exposes an API (/golang-sdk/test-api POST)
- Some Project adds my SDK as dependency
- The API (/golang-sdk/test-api) gets exposed from the service.
Thanks in Advance!!
P.S: If it is possible, any POC or document doing the same would be really helpful.
答案1
得分: 1
是的,这是可能的。你只需要在你的包的(一个或多个)init函数中注册你的HTTP处理程序:
package sdk
import (
"net/http"
)
func init() {
http.HandleFunc("/golang-sdk/test-api", TestHandler)
}
func TestHandler(w http.ResponseWriter, r *http.Request) {
// ...
}
只要你的包的用户使用DefaultServeMux,通过导入你的包,你的处理程序就会自动可用:
package main
import (
"log"
"net/http"
_ "your/sdk"
)
func main() {
log.Fatal(http.ListenAndServe(":3000", nil))
}
你的HTTP处理程序是公开的,因此它可以与任何其他ServeMux或第三方路由器一起使用,在替代路径下注册,用身份验证包装等等。
这正是标准库中net/http/pprof包的工作原理。你可以看一下,它很小。
它还展示了另一个良好的实践:为HTTP处理程序创建一个单独的包。仅仅导入runtime/pprof并不会注册HTTP处理程序。有一个单独的包来处理注册。向外部公开任何类型的功能应该是一个有意识的决定,而不是偶然发生的事情。
英文:
Yes, this is possible. All you have to do is register your HTTP handler in (one of) the init functions for your package:
package sdk
import (
"net/http"
)
func init() {
http.HandleFunc("/golang-sdk/test-api", TestHandler)
}
func TestHandler(w http.ResponseWriter, r *http.Request) {
// ...
}
As long as the user of your package uses the DefaultServeMux, your handler is automatically available by just importing your package:
package main
import (
"log"
"net/http"
_ "your/sdk"
)
func main() {
log.Fatal(http.ListenAndServe(":3000", nil))
}
Your HTTP handler is exported, so it can be used with any other ServeMux or third-party router, registered under an alternative path, wrapped with authentication, etc., etc.
This is precisely how the net/http/pprof package in the standard library works. Take a look, it's small.
It also shows another good practice: create a separate package for the HTTP handler. Just importing runtime/pprof does not register the HTTP handler. There's a separate package for that and only that. Exposing any kind of functionality to the outside should always be a conscious decision, never an accident.
答案2
得分: 0
欢迎,你会喜欢这个的:)
我能想到两种方法:
-
创建一个包含处理程序的包,并在导入的地方处理它们。这样,在导入的地方清楚地知道哪些端点进行处理。这种方式可以更好地控制,并且在我看来更容易维护。
-
在你的包含 REST API 的包中,有一个设置服务器处理程序的方法。你可以在 API 包的初始化中完成这个操作,这样每当导入
import _ "your_rest_package"
时,它就会自动启动服务器 - 这种方式可能不太可靠,而且可能更难维护。或者,在依赖于该 API 的包中创建一个启动 API 的方法,并在这些包中使用它。这样看起来更整洁,但我仍然不太推荐这种方式。
英文:
Welcome, you will like go
There are two approaches I can come up with:
-
Have a package with the handlers, and then handle them where you do the import. This way it will be clear what endpoints handle at the place where you do the import. You will have more control this way and imo it will be easier to maintain.
-
In your package with the rest API, have a method that setups the server with the handlers. You can probably do that in the init of the package with the API, so whenever it is imported
import _ "your_rest_package"
it will just start, it will start the server - this is shady and probably harder to maintain. Or have a method that starts your API and use it in the packages depending on it. It will look neath, but still I would not prefer this.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论