[giulianob]

How difficult is it to make the backend work with both new features and old features at the same time?

[thedufer]

To add to what bobby said, changes to the API are far more likely to be additions rather than actual behavior changes (except for bug fixes, which of course all clients handle fine). This makes it easy; old clients just ignore new routes/arguments.

[steveklabnik]

Thank you for this. I hope more people come to understand this more nuanced understanding of change. Please talk about it more!

[hamidpalo]

Another Trello dev here.

Basically, we have many clients that are consuming the API, including our mobile apps. We never change the published interface so that if you're getting some board fields that will always work. This means that we don't change the types of fields (for example string vs object) or the names of fields since that changes the published service contract.

What we do instead is add more fields. A very good example of this is emoji. We added emoji support a while back and instead of changing the "text" fields to be objects or embedding HTML (gah) into them we added another field called "textData" that has the extra info.

This is copy/pasted from an actual call for getting card actions:

        "textData": {
          "emoji": {
            "daft": "https://trello-emoji.s3.amazonaws.com/4f820a995a03e8e82d134ac4/ae846ca70bf7aa95dd3330b8fd1c70cb/art-daft-punk-steampunk-951631.gif"
          }
        },
        "text": "Custom emoji! :daft:"

This may not be sustainable in the long term and if it's not we'll version the API if we have to at that point. So far though, the API has proven itself to be very well designed and adaptable (thanks to @d_lec)

[irakli]

+100

[bobbygrace]

If there are necessary API changes, we just need to push updates to the API ahead of time. The API needs to be stable and backwards compatible anyway for the mobile apps (and all third party apps).