0

One Premise I worked under for API development is "The Consumer of the API adapts to the API." For example if I call Yelp or Twitter API I have to adapt to it. There is no way they are going to modify it for my requirements.

This leads me to an issue that has recently come up with a vendor. A vendor solution needs to call our APIs for integration. They are asking that we build our APIs per their spec (and there are some issues around best practices in how their APIs are designed).

This means we have to create an adapter to transform our GET/POST APIs (http error codes, properties) to match their spec. So that there are no coding changes / mapping / adapting required on their end when they call our APIs.

When working with a SaaS solution (that needs to consume data from your systems) and for that vendor to help with adoption of their software, I would still think the concept "The consumer of the API adapts" would apply and they should have an adapter layer.

Looking for best practices / thoughts on this approach from a wider audience.

Elim Garak
  • 119
  • 3
  • 3
    I would say "the side whose contract says that they are responsible for making the integration work adapts". – Jörg W Mittag Jun 06 '19 at 14:58
  • 1
    in case like you describe I would prefer to design an [anti-corruption layer](https://softwareengineering.stackexchange.com/q/184464/31260) on my side to communicate to that vendor in the way they require – gnat Jun 06 '19 at 15:02
  • 3
    The only answer forthcoming from this question is "how interested are you in keeping your customer happy?" If your API sucks, I think there's a bit more to it than "take it or leave it." – Robert Harvey Jun 06 '19 at 15:56

2 Answers2

2

Should the consumer of an API always be the one that should Adapt to the API Spec provided?

Rules with "always" in them seem to always forget about something.

We're done. Either use it or don't.

This attitude is how most API authors come by this power. There's also

Yeah, we're doing it this way now. Either use it or don't.

The only check on this power is to not use it. Which can be very effective, if they care.

The bottom line: features the customer cares about

Put those at risk and everybody cares. When you actually have a business relationship with the API author there can be room for negotiation. In a healthy relationship rather than simply arguing over who gets to set the specification, you'd discuss what features can and can't be supported with the current design. It being too much work to adapt to the API and support a feature is a perfectly valid concern.

However, requested changes shouldn't simply be motivated by the "pushing the work around" mentality. If you want the API changed and think you have a better design you are obligated to think about implications of changing the API from both sides. What problems are you causing on the other end? Are you willing to do this work? If not tread lightly before insisting others should do it.

I've dealt with this issue by asking the same person to write code on both sides of the API. That way the result is an API designed to work well on both sides.

I've also dealt with it by sitting down and having a real design discussion with the other side, putting myself in their shoes, and listening to what their concerns are.

If you assume good faith you normally get it. As long as you're prepared for things to fall apart you can negotiate knowing exactly what the consequences of failing to negotiating a change will be. Don't inflate that. Don't keep it a secret. Don't agree to do more work then you're prepared to do. But show that you're willing to do the work that it takes to get the API right.

At the very least your business case for changing the API should be more than, "I don't like it".

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • Actually, there is a check. It's the same check that's present in any for-profit enterprise: whether your customer likes your product well enough that you can still make money on it. – Robert Harvey Jun 06 '19 at 15:59
  • 1
    @RobertHarvey that's the same check. Not sure how you're hoping I'll edit this answer. – candied_orange Jun 06 '19 at 17:11
0

This should be treated like any other feature request: Does adding this feature justify the cost in time and effort required to implement it? Don't forget time and effort testing it, making sure it doesn't break any existing functionality, and the inevitable security analysis. Would that effort be better spent on other new features? Are they willing to pay you to add this feature? If you don't add the API like they want, will they go elsewhere and you lose the business?

1201ProgramAlarm
  • 1,529
  • 2
  • 14
  • 21