Explain the /{application}/{profile}/{label} endpoint the Config Server exposes: what does each path variable mean and how does it map to files in the backend?

app = spring.application.name, profile = active profiles, label = git ref
resolves application[-profile] + {app}[-profile] files
propertySources ordered most-specific-first
default label main (was master)
escape slash in label as (_)

basics

~20 s

application is the client's spring.application.name, profile is its active profile(s), and label is the git branch/tag (defaults to main). The server maps these to files like {application}-{profile}.yml on that branch and returns their merged properties.

solid answer

~40 s

The core endpoint is /{application}/{profile}[/{label}]. {application} matches a client's spring.application.name, {profile} is one or more comma-separated Spring profiles, and {label} is a backend version pointer — for git a branch, tag, or commit, defaulting to main (older setups master). The server resolves these to a set of files in the backend: application.yml (shared defaults), application-{profile}.yml, {application}.yml, and {application}-{profile}.yml, on the requested label. It returns an Environment JSON with a list of PropertySources ordered most-specific-first, so {application}-{profile} overrides the shared application.yml. There are convenience variants like /{application}-{profile}.yml and /{label}/{application}-{profile}.properties that return a single merged document in that format. Clients rarely hit these by hand — the config client library builds the request from its own name, profiles, and spring.cloud.config.label.

code

java · 24 lines

java

// Repo layout (git backend):
//   application.yml           -> shared defaults for ALL apps
//   application-dev.yml       -> shared dev defaults
//   orders.yml                -> orders base config
//   orders-dev.yml            -> orders dev overrides (highest precedence)

// GET http://localhost:8888/orders/dev
// -> Environment JSON, propertySources ordered high->low:
// {
//   "name": "orders",
//   "profiles": ["dev"],
//   "label": null,
//   "propertySources": [
//     { "name": ".../orders-dev.yml",     "source": { "timeout": "2s" } },
//     { "name": ".../orders.yml",         "source": { "timeout": "5s" } },
//     { "name": ".../application-dev.yml", "source": { "log.level": "DEBUG" } },
//     { "name": ".../application.yml",     "source": { "log.level": "INFO" } }
//   ]
// }
// Effective timeout = 2s (orders-dev.yml wins)

// Pin to a git branch/tag via label:
// GET http://localhost:8888/orders/dev/release-2.3
// Branch with slash: GET http://localhost:8888/orders/dev/feature(_)x

for a junior

Know the three variables mean app name, profile, and git branch, and that the server returns merged properties.

for a middle

Enumerate the resolved files and their precedence order; know the .yml/.properties convenience variants and the (_) slash escape.

for a senior

Explain precedence ordering of property sources, multi-profile requests, and dash-ambiguity gotchas when app names contain hyphens.

for a principal

Reason about repo layout conventions across many apps/environments and how the endpoint contract shapes a scalable config-repo strategy.

The endpoint family. @EnableConfigServer registers an EnvironmentController that exposes several equivalent URL shapes:

/{application}/{profile} — label defaults to the backend default.
/{application}/{profile}/{label} — explicit label.
/{application}-{profile}.yml, /{application}-{profile}.properties, /{application}-{profile}.json — return a single merged document in that format.
/{label}/{application}-{profile}.yml (and .properties/.json) — same, but pinned to a label.

The three variables.

{application}: the logical app name. A client sends its spring.application.name. In files this is the base name, e.g. orders.
{profile}: one or more Spring profiles, comma-separated (dev, or dev,us-east). It selects profile-specific files and their precedence.
{label}: a backend version pointer. For git it's a branch, tag, or commit SHA; the default is main (historically master), configurable via spring.cloud.config.server.git.default-label. For the native backend the label maps to a subdirectory if present. Because slashes in a label break URL parsing, use (_) as a placeholder (e.g. feature(_)foo for feature/foo).

File resolution. For /orders/dev, the server looks (in the git repo / search path) for, from lowest to highest precedence:

application.yml / application.properties — defaults shared by every app.
application-dev.yml — profile defaults shared by every app.
orders.yml — the app's non-profile config.
orders-dev.yml — the app's dev-specific config (wins).

What comes back. A Spring Cloud Environment object serialized to JSON: name, profiles, label, and propertySources — a list where each entry is a filename plus its key/value map. The list is ordered highest-precedence-first, and the client merges it using standard Spring property precedence, so the first source with a key wins.

Multiple profiles. /orders/dev,region-us activates both; region-specific files layer over dev, giving fine-grained overrides.

Gotchas.

The dash form is ambiguous when the app name itself contains a dash: /foo-bar-dev.yml — the server tries to split it, which is why the path-variable form /foo-bar/dev is safer.
Requesting a profile that has no file is not an error; you simply get fewer property sources (just the defaults).
A missing {application} still returns application.yml defaults, not a 404.
label slashes must be escaped as (_).

Why it matters. Understanding this mapping lets you predict exactly which file overrides which, debug 'my override isn't taking effect' issues, and reason about how one shared repo serves many apps and environments.

**The endpoint family.** `@EnableConfigServer` registers an `EnvironmentController` that exposes several equivalent URL shapes: - `/{application}/{profile}` — label defaults to the backend default. - `/{application}/{profile}/{label}` — explicit label. - `/{application}-{profile}.yml`, `/{application}-{profile}.properties`, `/{application}-{profile}.json` — return a single merged document in that format. - `/{label}/{application}-{profile}.yml` (and .properties/.json) — same, but pinned to a label. **The three variables.** - **{application}**: the logical app name. A client sends its `spring.application.name`. In files this is the *base name*, e.g. `orders`. - **{profile}**: one or more Spring profiles, comma-separated (`dev`, or `dev,us-east`). It selects profile-specific files and their precedence. - **{label}**: a backend version pointer. For git it's a branch, tag, or commit SHA; the default is `main` (historically `master`), configurable via `spring.cloud.config.server.git.default-label`. For the native backend the label maps to a subdirectory if present. Because slashes in a label break URL parsing, use `(_)` as a placeholder (e.g. `feature(_)foo` for `feature/foo`). **File resolution.** For `/orders/dev`, the server looks (in the git repo / search path) for, from lowest to highest precedence: 1. `application.yml` / `application.properties` — defaults shared by every app. 2. `application-dev.yml` — profile defaults shared by every app. 3. `orders.yml` — the app's non-profile config. 4. `orders-dev.yml` — the app's dev-specific config (wins). **What comes back.** A Spring Cloud `Environment` object serialized to JSON: `name`, `profiles`, `label`, and `propertySources` — a list where each entry is a filename plus its key/value map. The list is ordered highest-precedence-first, and the client merges it using standard Spring property precedence, so the first source with a key wins. **Multiple profiles.** `/orders/dev,region-us` activates both; region-specific files layer over dev, giving fine-grained overrides. **Gotchas.** - The dash form is ambiguous when the app name itself contains a dash: `/foo-bar-dev.yml` — the server tries to split it, which is why the path-variable form `/foo-bar/dev` is safer. - Requesting a profile that has no file is not an error; you simply get fewer property sources (just the defaults). - A missing `{application}` still returns `application.yml` defaults, not a 404. - `label` slashes must be escaped as `(_)`. **Why it matters.** Understanding this mapping lets you predict exactly which file overrides which, debug 'my override isn't taking effect' issues, and reason about how one shared repo serves many apps and environments.

How do you request more than one profile in a single call?
Comma-separate them in the profile segment, e.g. /orders/dev,region-us; both profiles' files are included with the later-listed profile layering appropriately, all above the base application.yml.
You have a branch named feature/new-timeout — how do you target it in the label?
Slashes break the URL, so escape them with (_): /orders/dev/feature(_)new-timeout. The server converts (_) back to / when resolving the git ref.

saying these in an interview costs you the question

Saying a missing profile file returns a 404 (it just yields fewer sources).
Claiming application.yml overrides {app}-{profile}.yml (precedence is reversed).
Forgetting that label slashes must be escaped as (_).

Explain the /{application}/{profile}/{label} endpoint the Config Server exposes: what does each path variable mean and how does it map to files in the backend?

answer

basics

solid answer

code

go deeper

context

Explain the /{application}/{profile}/{label} endpoint the Config Server exposes: what does each path variable mean and how does it map to files in the backend?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~2 min

▾common follow-ups2 questions

▾red flags3 flags

§ context

▾related questions4 questions

▾related topics3 topics

answer

go deeper

context