I am building a service with Laravel framework. I will be generating an API to be consumed by an Android and iOS app. At the same time, I will be making internal API calls to update my HTML/Blade views (or at a future time to update my SPA front end). All 3 clients (web, Android, iOS) will be developed by our team, so communication will - most likely - be easy!
I searched around a lot, and it seems that there are different approaches when it comes to API versioning (Best practices for API versioning? or https://apisyouwonthate.com/blog/api-versioning-has-no-right-way). What differentiates my question from the rest is how and by whom the API will be accessed. My API will be used to be simply consumed by our own applications (either web or mobile). Calls to our API will be generated by our own apps. No third party app will access this API.
I have several questions about this:
- Which is the correct approach for API versioning in this case? The developers that will consume the API will be in the same office, so there will be an app update each time we have a major API change.
- URI Versioning
- https://example.com/api/v1/users
- https://api-v1.example.com/users (as a subdomain)
- Resource Versioning (MIME Based)
- Accept: application/vnd.example.v1+json
- URI Versioning
- Is there a benefit in using a subdomain as the API versioning? Financially, if we use SSL, then we will need to purchase a wildcard SSL to accommodate the subdomain as well, so - in my eyes - it's worse.
- After deciding which path we will follow for API versioning, we need to choose how our users will be authenticated to our API. With Laravel you can authenticate to an API using a token, a JWT, Passport, etc. I am pretty sure that my service will not be used by other services for authentication, but does this remove Passport from my choices? Is it an overkill to implement Passport by having this in mind?
Thank you in advance!