You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the @JsonApiX annotation generates code with a single serialName value. However, when different endpoints return responses with the same serialName (e.g., "settings"), it results in conflicts during serialization/deserialization. This limitation prevents using the library effectively with APIs where multiple endpoints share the same type but deliver distinct payloads.
With the current library, deserializing these responses into JsonApiX models results in a conflict. By using a namespace or discriminator, the library can differentiate between the two.
🤔 Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered:
💡 Feature description
The current implementation of the @JsonApiX annotation generates code with a single serialName value. However, when different endpoints return responses with the same serialName (e.g., "settings"), it results in conflicts during serialization/deserialization. This limitation prevents using the library effectively with APIs where multiple endpoints share the same type but deliver distinct payloads.
ℹ️ Additional information
Example Use Case
{ "type": "settings", "aField": "value1" }
{ "type": "settings", "bField": "value2" }
With the current library, deserializing these responses into JsonApiX models results in a conflict. By using a namespace or discriminator, the library can differentiate between the two.
🤔 Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered: