오늘 학습한 내용
일정관리 앱 프로젝트 ERD 및 API 설계
Q. PUT과 PATCH 중 어떤 것을 사용해야 할까?
-
PUT은 리소스 전체를 교체할 때 사용하고, PATCH는 리소스의 일부만 수정할 때 사용.
-
‘전체 정보 수정’처럼 모든 필드를 업데이트하는 기능에는
PUT을, ‘상태 변경’처럼 특정 필드만 바꾸는 기능에는PATCH를 사용하는 것이 효율적.PUT은 구현이 간단하고,PATCH는 네트워크 효율성이 좋음.- 구현 복잡도를 낮추는 것이 더 중요하다면?
- 그냥
PUT만 사용하고, 클라이언트가 항상 전체 데이터를 보내도록 강제할수도 있음. - 많은 오픈 API들이 복잡성을 피하기 위해
PATCH를 아예 제공하지 않기도 함. - 실무에서는
PUT도 사용하지 않고,GET과POST2개만 사용하는 경우가 더 많은 것 같음.
- 그냥
-
프로젝트에서는 데이터의 일부만 변경하는 경우이므로
PATCH사용하여 기본을 익히고자 함.
Q. API 응답 시, HTTP 헤더의 상태 코드 외에 Body에도 별도로 상태 관련 정보를 만들어 넣는 것이 좋을까?
- 헤더의 상태 코드는 기계를 위한 정보, Body 안의 상태 정보는 API를 사용하는 개발자를 위한 정보라고 할 수 있음.
- Body에
statusCode,message,data가 포함된 형태로 일관된 응답 포맷을 만들어두면, 클라이언트 개발자가 성공/실패 여부를 판단하고 상세한 에러 원인을 파악하기 매우 편리
Q. DELETE 요청에 대한 응답은 어떻게 하는 것이 좋을까?
-
DELETE요청 성공 시 주로 사용할 수 있는 HTTP Status Code204 No Content(가장 표준적)- 의미: “요청은 성공적으로 처리했고, 응답 본문에 보낼 내용이 없다.”
- 특징:
204응답은 절대 응답 본문(Response Body)을 포함해서는 안 됨. - 사용: 클라이언트가 “삭제 성공” 여부만 알면 되는 명확한 상황에 사용.
200 OK- 의미: “요청을 성공적으로 처리했고, 응답 본문에 부가적인 정보를 담아 보낸다.”
- 특징: 응답 본문을 포함할 수 있음. 예를 들어, “삭제가 성공적으로 완료되었습니다.” 같은 메시지나 삭제된 리소스에 대한 정보를 담아 보낼 수 있음
- 따라서, 클라이언트 개발자가 일관되게 응답에 대한 핸들링을 하기에 편리 → 실무에서는 대부분 200 OK 및 공통된 Response 형식 사용
202 Accepted- 의미: “삭제 요청을 접수했지만, 아직 처리되지는 않았다.”
- 사용: 삭제가 비동기적으로(백그라운드에서) 처리되는 경우에 사용합니다.
-
프로젝트에서는 일단 기본적인 이론을 따르기 위해
204 No Content선택
더 알아볼 내용 / 다음에 할 내용
- Soft Delete (논리 삭제) 와 Hard Delete (물리 삭제)
- RESTful API 성숙도 모델 (Richardson Maturity Model)
- JPA를 활용한 Soft Delete의 효율적인 구현
참고