4 ms·

Or gradually increase the API latency so the system still produces correct results but the users are increasingly motivated to upgrade to the new API. I like t

• derefr 6y ago
  The problem with just adding artificial latency, is that it makes it unclear why latency is increasing. Users may think "maybe the upstream service is just gaining users and failing to scale." The great thing about an error, is that it gets your users' users upset (without really impacting them materially, if you're only doing them 1% of the time), in a way that tends to get your user to sit down and debug the problem. When they open their logs, they'll see your service's deprecation notice in each error message. If you're already thinking about this when designing your API response envelope format, you could have a "warnings" field to put information like that in. But a lot of devs are going to miss that entirely, because they've got your API wrapped in a gateway object that strips out everything but the data they're interested in for "successful" responses. They'll only actually pass any of the envelope stuff through in the case of an error.
  • cpeterso 6y ago
    That's a good point. An API error can include an error message explaining the problem (and solution!) to the client developer. You've changed my mind. :)