In Spring, where does update logic belong — the controller or the service?

The controller handles only the HTTP request/response boundary, while business rules such as the update live in the service layer. This problem follows the same structure.

How do you verify an update API?

Checking only that the requested value changed isn't enough. After the update, re-read the same data and confirm the intended part was applied as expected — that's a sturdier form of verification.

Member Name Update API

Your task

Build an API that changes a member's name. Take the new name and change that member's name. Complete MemberService.changeName. Note: PUT /members/{id}/name takes the new name.

Ground rules

•Single instance, in-memory H2.
•Member data is created directly through the repository in tests.

Not required

•Member signup and deletion APIs.
•Validating the name value itself (rejecting empty names, etc.).

▶About this challenge

Complete an API built on Spring Boot 3 and JPA (in-memory H2) that changes a member's name. It takes a new name, changes that member's name, and returns the updated member with a 200. The controller handles only the HTTP boundary while the update logic lives in the service.

An update API that changes only part of already-stored data centers on deciding how the values in a request map onto an already-stored row. This question — what happens to each field when a request arrives — is a pattern that recurs across update APIs. This problem practices that update flow against existing member data.

In Spring, where does update logic belong — the controller or the service?: The controller handles only the HTTP request/response boundary, while business rules such as the update live in the service layer. This problem follows the same structure.
How do you verify an update API?: Checking only that the requested value changed isn't enough. After the update, re-read the same data and confirm the intended part was applied as expected — that's a sturdier form of verification.