A new chapter in the Requirements & API series continues uncovering API design specifics. This time, we look closer into IDLs (Interface Definition Languages).
I examine OpenAPI as an industry standard, Microsoft-powered rival TypeSpec, and an underdog JSight. They have a similar purpose but achieve that in very different ways.
A new chapter in the Requirements & API series focuses on structuring each layer to design an API. This time, it is more practice-oriented, with examples of an HTTP API call and its OpenAPI definition.
I am in the hallway through that series. Almost a year ago, I did two webinars on the topic. Those articles help look deeper into the topic, which is better done in writing.
Last month, I started summarizing all my API-related posts, workshops, and webinars into extended and structured reading. That is usually a part of the Essays section, where you can find my recent Replacing Legacy series.
Reflecting on my past materials about API, I realized they were disconnected and lacked a logical narrative. However, I am proud to share that I am starting anew, from simple concepts to in-depth reviews of various Interface Definition Languages, showing significant improvement in my approach.
The new chapter, "Analysis," focuses on business analysis and aspects of requirements engineering. That was tough to write and edit, cutting pieces that did not fit and made text difficult to comprehend. Hopefully, I will get a satisfactory result.
For those who are not Medium fans, I've packed the Replacing Legacy series into the long read available on my blog.
There are some slight differences from the original: some passages have been edited, and others have been removed. Text is now more straightforward, but there are still a lot of places for improvement.
Now everything is in one place. I hope you enjoy reading.
And a few more updates:
-> I keep experimenting with formats and media platforms. Now, I will no longer publish unique content on one platform, like I did with the above-mentioned series on Medium.
I will simultaneously post on Medium and my blog. On LinkedIn, I publish a link to the blog with a short summary. So there will be a choice of where to read. And I will not spend time again migrating content from one place to another.
I am unsure about maintaining LinkedIn Articles, as last year's experience was not the best. The traction was minimal compared to a usual post.
I wanted to conclude the Replacing Legacy series with something less practical and more philosophical. Here are my thoughts on why we are at this point of rapid and sometimes senseless replacement or modernization. And what does the future bring us in the face of AI?
I did some research for the AI part and felt a lack of knowledge to read scientific papers. Like one about the CARGO algorithm, I mentioned in the article. I really tried, but I cannot fully understand the details. That is a considerable gap to be addressed.
I recently bought a course about Product Management in AI, but I am unsure how technical it is. I still don't know how to embed that course into my schedule.
Here is the entire series at the moment:
That piece was quite difficult to write. I started it as a more personal story of overcoming burden of moving and adapting business logic from one system to another. I spent multiple days trying to shape and structure but every time that ended up as a whinning on the past experience with no particular clue.
So, I decided to follow the formal approach of listing some general difficulties and humble options how to resolve them. If they can be resolved at all.
Next time I will try not to overthink for 3 months in a row.