Your company provides a recommendation engine for retail customers. You are providing retail customers with an API where they can submit a user ID and the
API returns a list of recommendations for that user. You are responsible for the API lifecycle and want to ensure stability for your customers in case the API makes backward-incompatible changes. You want to follow Google-recommended practices. What should you do?
To ensure stability for customers in case the API makes backward-incompatible changes, the best approach is to use a versioning strategy for the APIs that increases the version number with every backward-incompatible change. This allows developers to introduce changes without disrupting the existing users of an API. It is a widely accepted practice in API development to manage and communicate changes clearly and effectively.
It is C
https://cloud.google.com/apis/design/versioning
more specifically: https://cloud.google.com/apis/design/versioning#release-based_versioning
Answer C All Google API interfaces must provide a major version number, which is encoded at the end of the protobuf package, and included as the first part of the URI path for REST APIs. If an API introduces a breaking change, such as removing or renaming a field, it must increment its API version number to ensure that existing user code does not suddenly break.
I had a test today. The overall question was almost the same, but question mentioned Apigee.
The correct answer is: C. Use a versioning strategy for the APIs that increases the version number on every backward-incompatible change. A versioning strategy for the APIs that increases the version number on every backward-incompatible change is the best way to ensure stability for your customers in case the API makes backward-incompatible changes. This will allow you to track the changes that have been made to the API and allow your customers to easily identify the latest version of the API.
C is the correct answer
option C
C is ok
If 'A' is the correct answer, one would wonder why. The new version might be back-ward incompatible but does not necessarily mean its a breaking one. In that case A might be sufficient, although C remains mandatoryBest Practice imho.
See @seafranek comment
c version numbers cannot be changed as given in d
Clearly C
Anyways option A is also a recommended best practice. Its version incompatible change afterall.
Maybe A on top of C but are we really going to mandate customers only have 1 month to be ready? I don't think so, use the version strategy and let them migrate when ready!
C is correct
This is not a GCP-specific or even cloud-specific question, but a development best practice. No need to look at other options.
Answer is A Question asks: You are responsible for the API lifecycle and want to ensure stability for your customers in case the API makes backward-incompatible changes. Option C is a must for the API lifecycle but doing only that will not help your customers. In my opinion they have to be notified of backward-incompatible changes with time enough to stay ready
Breaking changes = version bump in the API url