Approach on API/System design

Question

I was watching a video on "Design Uber api mock interview".

for most of the APIs, the candidate just used "userId" and left on the system to resolve "rideId"

Example - cancelRide(userId: string)

For this api, user is just passing userId to cancelRide endpoint and now the system will have to resolve rideId to actually cancel the ride.

Now this may solve the problem at hand but in future Uber may want to enable multiple ride for single user (you can book ride for yourself and your mom too, at the same time)

With this kind of API design now we will have to make changes to cancelRide endpoint to accept rideId as well

cancelRide(userId: string, rideId: string)

Should we just design as per the problem at hand and make changes to the API/Design if there is some new requirement is coming in or We should at least consider some obvious/possible future requirements/change?

Answer 1

You should think ahead: What is the potential requirement/change they need in the future?

The reason is you are developing an API.

Assume that you have more than 100K external clients of your API, any change will enforce them to update, modify, rebuild their APP and a lot of work.

Thus, the YAGNI principle is inappropriate to API design issue. You should try the Open-Closed Principle (OCP).