I have a situation where I needed to migrate my codebase from using Joda time to Java 8 date time library, for this reason I changed the data type of a few parameters in my request and response object classes for my JSON_RPC API from Joda DateTime to ZonedDateTime type.
The serialized JSON representation for these remains the same so there should not be any issue at runtime, the problem arises that the clients of this API have not migrated their code from Joda to Java time, so they are getting compile time issues related to the request and response objects, due to mismatch in Joda and Java time data types.
Now I don't believe doing this is a breaking change, since from a API contract point of view the backward compatibility remains the same, the only issues are at compile time. But the clients insist that they want some form of backward compatibility, they suggested instead of changing the data type of existing attributes I instead create new attributes that they can then switch to on their end.
Is this a valid way to achieve backward compatibility in this situation ?.
I feel adding new parameters will result in a lot of code changes in my codebase cause I will have to handle both the old and new values everywhere till the clients have fully migrated. Is there a better way to achieve backward compatibility with less amount of changes required in my codebase. Perhaps URI versioning if that's even possible in JSON-RPC ?