TIL / RESTful API

📅 Today I Learned

오늘은 RESTful API를 공부하면서, 그동안 내가 ‘표면적으로만’ 이해하고 있던 부분을 바로잡을 수 있었다.
특히, HTTP 메서드가 핵심이라고 착각했던 부분을 구체적인 코드와 함께 정리했다.

---

🚧 내가 처음 작성한 코드

이 코드를 작성하면서 그냥 http매서드를 목적에 맞게 사용하는 것이라고만 생각했다. 즉, 데이터를 조회할 때는 GET, 수정할 때는 PUT 정도의 규칙만 잘 지키면 RESTful API가 된다고 생각했다. 

@GetMapping("/schedules/{author}")
public ResponseEntity<List<GetOneScheduleResponse>> getAllSchedule(@PathVariable String author) {
    List<GetOneScheduleResponse> all = scheduleService.getAll(author);
    return ResponseEntity.status(HttpStatus.OK).body(all);
}

@PutMapping("/schedules/{userId}")
public ResponseEntity<UpdateScheduleResponse> updateSchedule(@PathVariable Long userId, @RequestBody UpdateScheduleRequest updateScheduleRequest) {
    UpdateScheduleResponse update = scheduleService.update(userId, updateScheduleRequest);
    return ResponseEntity.status(HttpStatus.OK).body(update);
}

---

💡 RESTful의 핵심은 HTTP 메서드가 아니다!

• RESTful URL은 “무엇(자원)”을 표현하는 명사 중심의 구조이며 “어떻게(행위)”는 HTTP 메서드로 구분한다.
  URL은 ‘데이터의 위치’를 나타내야지, ‘행동’을 표현하면 안 된다.
• 헷갈렸던 URL규칙 
  • 계층 구조를 이용해 관계 표현: /users/1/orders/5 (1번 유저의 5번 주문)
  • 필터링이나 정렬은 쿼리 파라미터로: /products?category=phone&sort=price
  • 리소스 식별은 Path Variable로: /users/{userId}

---

🧠 정리

RESTful API는 단순히 HTTP 메서드를 쓰는 규칙이 아니라,

리소스를 중심으로 URI를 설계하고, 그 리소스에 대한 행위를 HTTP 메서드로 표현하는 구조적 원칙이다.