Adding fields. Will we break you?

Avatar image for rick
rick

507

Forum Posts

33

Wiki Points

0

Followers

Reviews: 1

User Lists: 1

If we were to add fields to some of the API results we wouldn't break you. Right? None of you are silly enough to have written your own DTD for an XML feed. Right? Yeah...?

Avatar image for 3van
3van

22

Forum Posts

1

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

If this breaks someone, it's time for them to re-visit their approach regardless.

Avatar image for chaser324
chaser324

9415

Forum Posts

14945

Wiki Points

0

Followers

Reviews: 1

User Lists: 15

#3  Edited By chaser324  Moderator  Online
Avatar image for thefaxman
TheFaxman

70

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

@edgework: One thing that I think really helped when the site & API redesign hit was the beta endpoint we could test our apps against (I found a number of bugs and regressions this way). While I don't suspect adding fields is a big deal for most apps it would be great if you could stand up a beta endpoint so people can test and give you feedback before launch.

Avatar image for rick
rick

507

Forum Posts

33

Wiki Points

0

Followers

Reviews: 1

User Lists: 1

@thefaxman: Why can't you use the production endpoint. Its read only so crappy code can't hurt it... Am I missing something?

Avatar image for thefaxman
TheFaxman

70

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

@edgework: It's mostly about minimizing end user impact when API changes occur. There's two real categories here:

1.) A bug in the app itself often due to assumptions. In this case by testing against a beta endpoint the app author can fix the bug before their users are impacted by it. This is more impactful when the upcoming changes are fairly big.

2.) A regression in the API. In this case it gives the opportunity to provide feedback to you guys earlier and reduce impact.

During the seaserpent beta I found a bunch of bugs in my app that fell into #1 and quite a few that fell into #2. Both ended up getting fixed before the rollout because of the beta endpoint and my end users saw no real impact. If the changes had just been deployed I probably would have had at least a week's worth of disruptions while I worked through issues. Like I said before I don't suspect what you asked about is really impactful this is more of a general suggestion. I know that having a beta endpoint to test against is more work for the engineering teams so I can appreciate that it may or may not be the right thing here.

Avatar image for soup_menu
soup_menu

293

Forum Posts

26

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

#7  Edited By soup_menu

Well said, @thefaxman. Any time there's a change there's a chance that an issue could crop up and it would be unfortunate if end users were the ones taking the brunt of the impact. In this specific case if we're just looking at adding fields without altering the existing structure/behavior then the risk is probably pretty low, but I tend to be a measure-twice-cut-once sort of guy so I would probably advocate for a brief beta period just to be safe.

Avatar image for rick
rick

507

Forum Posts

33

Wiki Points

0

Followers

Reviews: 1

User Lists: 1

@thefaxman: Oh OK, I get it. Uhh... Our 'beta' endpoint is our staging server and that's not accessible from outside of the CBSi main office. Even remote VPN employees can't get to it so that's not gonna work. What I would suggest is that you send us an automated test that we can run. If it fails its likely our fault and we'll fix it. If its your fault we'll mock you all over the forums and Twitter. JK, Actually we'll just let you know...