Review API design of org.springframework.ai.image (#326) #4736
Conversation
…nseFormat (spring-projects#326) Signed-off-by: Kuntal Maity <kuntal.1461@gmail.com>
…nseFormat (spring-projects#326) Signed-off-by: Kuntal Maity <kuntal.1461@gmail.com>
There was a problem hiding this comment.
While I would typically be in favor of such strongly typed changes, I wonder if this is really desirable.
Do all providers really agree on values? For example, you changed one test value from base64 to b64_json. Was it intentional? Or was it an oversight exactly because a strong type gives you confidence?
Moreover, do all providers really support (and will they always) support all values of the enum?
| .width(1920) | ||
| .style("sketch") | ||
| .responseFormat("base64") | ||
| .responseFormat(ImageResponseFormat.B64_JSON) |
There was a problem hiding this comment.
This looks like a change of semantics here
| @Override | ||
| public String getResponseFormat() { | ||
| return this.responseFormat; | ||
| return (this.responseFormat != null) ? this.responseFormat.getValue() : null; |
There was a problem hiding this comment.
Assuming we carry through with this change (see my overall comment on the benefits of this PR), could we try to push the null check inside the enum (for example having ImageResponseFormat.NULL a value, and setting all options to that)
2 participants
Summary
This PR contributes to issue #326 by improving the API design of org.springframework.ai.image:
Introduces a new ImageResponseFormat enum for strongly typed response formats.
Aligns ImageOptions across providers (OpenAI, Azure OpenAI, Stability, ZhiPuAi).
Updates tests accordingly.
Enhances documentation to reflect the new type-safe format property.
Ensures observation and response metadata consistency.
This aligns image models with improved usability and type safety.
Testing