How do @Projection interfaces and an excerptProjection change the exposed representation in Spring Data REST?

**Projections** let you decouple the *exposed representation* from the JPA entity's full shape — hiding fields, adding computed values, or inlining related data. **Defining a projection:** ```java @Projection(name = "summary", types = { Book.class }) public interface BookSummary { String getTitle(); @Value("#{target.author.name}") String getAuthorName(); } ``` It is a plain interface. Its accessor methods name the entity properties to expose. Anything not listed is omitted from the representation. **Closed vs open projections:** - **Closed projection** — every getter maps directly to an entity property (e.g. `getTitle()` → `title`). Spring Data can then generate an optimised query selecting only those columns. - **Open projection** — a getter is annotated with `@Value("#{target.author.name}")` (SpEL). This computes values or reaches into associations, but Spring Data must load the *entire* backing entity, losing the column-selection optimisation. **Registration:** A projection is discovered automatically if it lives in the **same package as, or a sub-package of, the entity** it targets. Otherwise you register it explicitly: ```java config.getProjectionConfiguration().addProjection(BookSummary.class); ``` inside a `RepositoryRestConfigurer`. **Requesting a projection:** Clients add `?projection=summary` to the URL. The response then uses that shape. Spring Data REST advertises available projections in the `profile` metadata. **excerptProjection — the key exam point:** ```java @RepositoryRestResource(excerptProjection = BookSummary.class) public interface BookRepository extends JpaRepository<Book, Long> { } ``` An **excerpt projection** is the projection applied *by default* when a resource appears **inside a collection** — i.e. every item under `_embedded.books` uses `BookSummary` automatically, without `?projection`. It is also used when the entity appears as an association resource. The **major gotcha**: the excerpt is deliberately **NOT** applied to the *single-item* resource (`GET /books/1`) to avoid the client mistaking a partial view for the full editable resource. To get the excerpt on a single item you must explicitly request `GET /books/1?projection=summary`. **Additional gotchas:** - Excerpts add value by *inlining associations* into collection responses (fewer round-trips) — a common motivation is to embed `author.name` directly instead of forcing a follow-up call per book. - Projections are **read-only** shaping; they do not affect writes (PUT/PATCH still target the full entity). - A projection must be an interface (class-based DTO projections exist in Spring Data query methods but Spring Data REST projection resolution expects the `@Projection` interface). - If an excerpt inlines heavy associations for a large collection, you can reintroduce the N+1 / over-fetch problem you were trying to avoid. **When to use:** projections for tailored read views (mobile summary vs full detail); excerptProjection specifically to enrich collection listings so clients don't have to follow every association link.