github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #3487] Expose API via swagger-ui #48659

New Issue
Closed
opened 2026-04-28 09:02:29 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-28 09:02:29 -05:00
Owner
Copy Link

Originally created by @haferwolle on GitHub (Apr 4, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/3487

What are you trying to do?

Using the ollama REST API. It's possible, but could be better.

How should we solve this?

The API is described here: https://github.com/ollama/ollama/blob/main/docs/api.md
However, it is so much more convenient to use an API with a SwaggerUI, especially in the initial phase and to see all available endpoints. There should be a library for golang, which just does that automatically.

What is the impact of not solving this?

TL;DR Exposing your API as OpenAPI specification opens it up to the entire OpenAPI ecosystem and tools, which makes it much more accessible/usable.

Making your product accessible contributes tremendously to its success. Exposing the API via OpenAPI/swagger-ui not only provides a convenient way to see and use all available endpoints. It also allows to use OpenAPI tools like OpenAPI code-gen, to generate client libraries for basically any programming language. I have seen ollama Java clients developed on github, which is not necessary. With an OpenAPI specification in place a Java client library can be autogenerated with OpenAPI code-gen.

Anything else?

No response

Originally created by @haferwolle on GitHub (Apr 4, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/3487 ### What are you trying to do? Using the ollama REST API. It's possible, but could be better. ### How should we solve this? The API is described here: https://github.com/ollama/ollama/blob/main/docs/api.md However, it is so much more convenient to use an API with a SwaggerUI, especially in the initial phase and to see all available endpoints. There should be a library for golang, which just does that automatically. ### What is the impact of not solving this? TL;DR Exposing your API as OpenAPI specification opens it up to the entire OpenAPI ecosystem and tools, which makes it much more accessible/usable. Making your product accessible contributes tremendously to its success. Exposing the API via OpenAPI/swagger-ui not only provides a convenient way to see and use all available endpoints. It also allows to use OpenAPI tools like OpenAPI code-gen, to generate client libraries for basically any programming language. I have seen ollama Java clients developed on github, which is not necessary. With an OpenAPI specification in place a Java client library can be autogenerated with OpenAPI code-gen. ### Anything else? _No response_
GiteaMirror commented 2026-04-28 09:02:31 -05:00
Author
Owner
Copy Link

@jimscard commented on GitHub (Apr 7, 2024):

See also #3383 for more support for providing an OpenAPI specification and maintaining it. The OpenAPI specification mentioned in #3383 is required to use the SwaggerUI tool to make it easily accessible.

<!-- gh-comment-id:2041301159 --> @jimscard commented on GitHub (Apr 7, 2024): See also #3383 for more support for providing an OpenAPI specification and maintaining it. The OpenAPI specification mentioned in #3383 is required to use the SwaggerUI tool to make it easily accessible.
GiteaMirror commented 2026-04-28 09:02:32 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (May 15, 2024):

Thanks for the issue! Let's close this as a dupe of #3383

<!-- gh-comment-id:2111387841 --> @pdevine commented on GitHub (May 15, 2024): Thanks for the issue! Let's close this as a dupe of #3383
GiteaMirror commented 2026-04-28 09:02:32 -05:00
Author
Owner
Copy Link

@haferwolle commented on GitHub (May 15, 2024):

@pdevine Thanks for taking care of this so quickly.

<!-- gh-comment-id:2111839422 --> @haferwolle commented on GitHub (May 15, 2024): @pdevine Thanks for taking care of this so quickly.
GiteaMirror commented 2026-04-28 09:02:34 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (May 15, 2024):

@haferwolle I'm sorry its taken a bit to get to the issue. The project has taken off and it's hard to balance issues/PRs/new models/features. We're a small team, so its meant a lot of long days/nights.

W.r.t. OpenAPI the last I looked there isn't really a good annotation to OpenAPI 3.0 tool/framework. I've used go-swagger in the past, but it's only for OpenAPI 2.0. I haven't looked recently, so I'm not sure if such a thing exists. The reverse (i.e. generating routes from an OpenAPI 3.0 spec) is probably not feasible given the state of the project right now, nor would it buy us that much. We could do a separate swagger definition, but I'd worry that it would drift from the actual implementation pretty quickly.

<!-- gh-comment-id:2111872856 --> @pdevine commented on GitHub (May 15, 2024): @haferwolle I'm sorry its taken a bit to get to the issue. The project has taken off and it's hard to balance issues/PRs/new models/features. We're a small team, so its meant a lot of long days/nights. W.r.t. OpenAPI the last I looked there isn't really a good annotation to OpenAPI 3.0 tool/framework. I've used `go-swagger` in the past, but it's only for OpenAPI 2.0. I haven't looked recently, so I'm not sure if such a thing exists. The reverse (i.e. generating routes from an OpenAPI 3.0 spec) is probably not feasible given the state of the project right now, nor would it buy us that much. We could do a separate swagger definition, but I'd worry that it would drift from the actual implementation pretty quickly.
GiteaMirror commented 2026-04-28 09:02:35 -05:00
Author
Owner
Copy Link

@haferwolle commented on GitHub (May 15, 2024):

@pdevine No worries, great to see things moving.
I'm not a golang developer, otherwise I'd love to join your team. In Java, I use a library called springdoc-openapi, which auto-detects all my REST controllers and endpoints/payloads. Based on that it generates an OpenAPI spec and even serves an embedded swagger-ui. All I need to do is add the library as a dependency. It takes 5 minutes. I especially like the code-first approach, because I always start with developing REST endpoints. I never start with the OpenAPI spec. The library just constantly updates the OpenAPI/swagger based on my code changes. So that's super simple and just enhances my services with no additional effort for me.
For golang I found this project, which seems to be doing a similar thing: https://github.com/swaggest/rest?tab=readme-ov-file
Maybe it helps.
Keep up the good work!

<!-- gh-comment-id:2111926481 --> @haferwolle commented on GitHub (May 15, 2024): @pdevine No worries, great to see things moving. I'm not a golang developer, otherwise I'd love to join your team. In Java, I use a library called springdoc-openapi, which auto-detects all my REST controllers and endpoints/payloads. Based on that it generates an OpenAPI spec and even serves an embedded swagger-ui. All I need to do is add the library as a dependency. It takes 5 minutes. I especially like the code-first approach, because I always start with developing REST endpoints. I never start with the OpenAPI spec. The library just constantly updates the OpenAPI/swagger based on my code changes. So that's super simple and just enhances my services with no additional effort for me. For golang I found this project, which seems to be doing a similar thing: https://github.com/swaggest/rest?tab=readme-ov-file Maybe it helps. Keep up the good work!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#48659
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?