When you are orchestrating an interaction between several services where they are all using a shared identifier somewhere in their API, you need to extract that identifier if it's embedded in a URI.

So tonight we're going to regex like it's 1999.

The identifier is not embedded in a URI, the identifier is a URI: instead of an integer id 1234 or a string id "1234", you can use a string id "http://example.com/id/1234". Typically, one service is responsible for creating the id but after that, it can be used to refer to the same entity in any number of services. EDIT: What makes it better than a free-format string id is that every person and tool knows how to de-reference it / look it up.

What determined which API owns a resource when the same resource is exposed in mutlipe apis (e.g you have a REST API and a AMQP feed)? In some cases it is obvious but in other cases it is far from clear.

I feel using urls as ids create more problems than it solves, especially if you use absolute urls. I have worked with cases where the same ID was used in 3 or 4 different APIs. None of them clearly the master.

The URI doesn't have to be fully owned by any single microservice. The JSON representation can more or less correspond to a HTML view and be served by the UI, or a separate API facade can combine the relevant pieces of information from various microservices.

Most modern ecosystems have fantastic URL parsing that does not rely on regex and should not be written again by hand.

You would still often need to parse them. Imagine that the url is the primary key of a table and the API changes url structure. Then you would get duplicate rows and the only way to prevent that would be to validate the format of the urls, which is parsing. The index would also be bloated and slow.