earlier replies
Replying to @mdennis
@mdennis @stilkov If you broke (not additive) contract of a resource is it really the same resource anymore? Why invalidate all resources?
1
@kellabyte @mdennis @stilkov you don't invalidate them, they stay under /vX and continue to work under that contract
1
@faltering @mdennis @stilkov IMO unnecessary. We have formats that tolerate additive changes & if A no longer resembles B its not a version.
2
@kellabyte @faltering @mdennis +1. If it's compatible, no need to change its name; if not, little use in similar names
3
@stilkov @kellabyte @faltering @mdennis only clients can claim compatibility…
1
@sgrasmann @stilkov @faltering @mdennis Testing can’t claim compatibility?
2
@kellabyte @sgrasmann @stilkov @faltering so all clients of a public API should test new code before it is pushed?
1
@mdennis @sgrasmann @stilkov @faltering No, services test that they still uphold the contracts.
1
@kellabyte @sgrasmann @stilkov @faltering the contract is "do what you were doing before you changed the code and broke my app"
2
@mdennis @kellabyte @stilkov @faltering then API consumers can extend the test suite to enforce their usage. Test suite is the contract.
2
Replying to @sgrasmann
@sgrasmann @mdennis @kellabyte @faltering Old but still good article by @iansrobinson that elaborates on that idea: martinfowler.com/articles/co…

Dec 5, 2012 · 7:52 PM UTC

3
Replying to @stilkov
@stilkov @sgrasmann @mdennis @faltering @iansrobinson I was just Googling for that to link it. Beat me to it :) Another good one on InfoQ
Replying to @stilkov
@stilkov @mdennis @kellabyte @faltering @iansrobinson Nice article. What I'd like to add: it's often the subtle things that break contracts.
Replying to @stilkov
@stilkov @mdennis @kellabyte @faltering @iansrobinson like http status codes or elements optional for the server but important for clients