Add support for v1/responses API (upstream and client) no persistent storage #622
Conversation
|
pls update the description and title |
adilhafeez
left a comment
adilhafeez
left a comment
There was a problem hiding this comment.
I looked at some parts of the code but it seems like you moved code around and did some refactoring. It becomes quite difficutl to track the changes. Let's do refactor / rename in separate PRs so its easier to look at the change. I will review it again tomorrow morning.
| async move { | ||
| match (req.method(), req.uri().path()) { | ||
| (&Method::POST, CHAT_COMPLETIONS_PATH | MESSAGES_PATH) => { | ||
| (&Method::POST, CHAT_COMPLETIONS_PATH | MESSAGES_PATH | OPENAI_RESPONSES_API_PATH) => { |
There was a problem hiding this comment.
Why prefix with openai when other path don't have openai in them?
consider changing OPENAI_RESPONSES_API_PATH => RESPONSES_API_PATH
There was a problem hiding this comment.
responses is specific to OpenAI while chat/completions is supported by many upstream providers like Grok. The one thing we can do, however, is to rename MESSAGES_PATH to ANTHROPIC_MESSAGES_API_PATH to be more consistent.
|
Agree that you are paying some review time penalty. But without the refactor and renames, the code looked very sloppy. For example, responses.rs was handling both streaming and non-streaming logic, which made it hard to update, validate, and test without first breaking that functionality into separate modules especially as we added buffer support. Similarly, the new stream buffer shapes warranted a dedicated home, and forcing them into the old layout would have created inconsistencies with how other streaming types are organized. In my humble opinion, doing this kind of “small” refactoring while we’re already touching the code is actually cheaper and safer than postponing it. If we defer these cleanups, we eventually end up with a big, standalone refactor that doesn’t ship new functionality, is harder to review, and is more likely to break things. A bit of refactor and renaming here is good hygiene—it keeps the codebase evolving incrementally instead of forcing us into disruptive, high-risk rewrites later. Unless there are architectural flaws, structural problems or poor test coverage, I would encourage you to look at how the code pushes us forward. |
salmanap
changed the title
salmanap
changed the title
No description provided.