What I Don't Want to Hear About API Management Projects
When it comes to APIs, there are some things I prefer not to hear!
Join the DZone community and get the full member experience.Join For Free
This is a continuation of my series, "What I don't want to hear anymore." This time around is APIs. A subject that reoccurs from time to time, even if the buzz has decreased a little. Nevertheless, the literature, which is very prolific on the subject, has obviously not motivated everyone to learn and frame their APImManagement projects.
You may also like: What I Don’t Want to Hear From a Dev Anymore
APIs Without Vision
"We want APIs!"
"Yes, great, but why?"
"Because they're good."
"Uh, yes, but are you sure you need them?"
"Well, you're the one who's going to tell me since you're so smart!"
I don't know if I'm the smartest, but at least I'm smart enough to tell that a technology must meet a need. You want APIs to monetize them, to facilitate integration work, and to secure your backends, but not because it looks good!
Without vision, it is difficult to have a large API platform, a good framework, and its associated governance. In short, it's complicated to have a good delivery!
APIs Without Knowledge of Business Objects
"It's necessary to make an API that will restore the contracts contained in SAP."
"Oh, no, if you can find others, that's good."
"Ah, and where can I find them?"
"Elsewhere I'm sure, but I can't tell you where."
"Oh, well, I'll get it then..."
And that's when your fear begins! Where will I find contracts? Will I be able to reconcile data from several systems? And what is the definition of a contract in my company? Which fields? Do I run the risk of having to reconcile two different verbiages from two different systems?
APIs Without a Roadmap
"I want SAP contracts."
6 months later
"I want the contracts of our second SAP."
"Do you think you could have told me that six months ago?"
Without an API roadmap, you can't manage your APIs in the best way, you'll waste time unnecessarily, and you'll have to change your API and explain it to current consumers. Please make the effort to have an API roadmap!
"Hello, I'm the Super Client Portal project, and I want APIs."
"Great! What business objects do you need?"
"Don't bother me with your verbiage, I want my own API!"
"Well, yes, but it would help me to have a reusable API."
"This is my API!"
And that's how you end up with an API called "Super Customer Portal"! For the review, we'll come back. For the urbanization of business objects as well. For the understanding of the interest of APIs too. In fact, we could have done without the API management too, couldn't we?
APIs Without Documentation
I find it hard to want to make the effort to explain the interest because it seems so obvious to me!
Your API must be readable by both a project manager and a developer. Period!
Complex API Processes
Wishing for APIs, which make it possible to agilize development, define processes to extend, and prohibit intermediate versions of work, there is nothing more annoying. There's nothing to stop you from making a hard API to unlock developers and then modifying it to make it clean and well-defined. WE'RE AGILIZING!
APIs That Are Not Consistent With Each Other
There is enough documentation on API good practices for you to define them quickly at the beginning of the project! And having an HTTP PUT call to recover data, no it's not possible! The idea is to help and facilitate the life of developers, not to have as many different ways to call an API as there are APIs on your platform. What about you? What do you no longer support on the API projects you have seen?
Opinions expressed by DZone contributors are their own.