Tell me you don't version your APIs without telling me you don't version your APIs.

You version your APIs, but do you version your services ?

Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.

So? Have you heard of API Gateway and/or HTTP routing based on path prefix or header?

You're right about the external interface, but you still need to give a name to the actual service behind the URL.

From your point on versioning, I'd assume you'd actually call it UserProfileV2 ?

PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.

It depends on the language, but I would probably call it `UserProfile` and change a major version even if it's in an entirely different language. Maybe even kept in the same repo.

> PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.

From what it said in the original comment, it still seems like a user profile to me.

You def don't want a new DB and for it to be under new repo

I mean, I'd call it the FaceBook in the first place but I'm already on team whimsical.

Some of you are thinking, well, what if you need to interface with facebook dot com? Easy, I'd call it the SneedFeed. If you know you know.

UserPersona, where a single UserProfile may have multiple UserPersonas?

> Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ?

Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?

You got me confused.

UserProfile2

Us3rPr0f1le

NewUserProfile, obviously :-)

YeOldeUserProfile