기능정의

{ "name": string, "notifyEmail": bool, "publishJandi" : bool,

“ }

api문서

• 리퀘스트 모델
  • 서버의 데이터를 생성하거나 변경 (post, patch, put)
  • put/patch는 어떤 내용을 수정할지 서버에 보내야 하기 때문에 리퀘스트가 무조건 필요
  • get/delete는 보통 url이나 쿼리 파라미터로 결정하므로 body를 쓰지 않는게 표준
• 리스폰스 모델(에러 상황)
  • 서버가 작업을 마친 후 결과물을 보여줘야 할 때 (거의 다 해당)
  • 모든 메소드는 에러 발생 시 공통된 에러 모델을 반환하는 것이 좋음
  • {"detail": "에러 메시지", "code": "ERROR_CODE"}
• 토큰 필요 여부
  • 조회(get)이나 회원가입/로그인(post) 제외, 대부분 데이터 조작(put, patch, delete)은 본인 확인이 필요하므로 토큰 필수

리퀘스트 모델(Body) 서버에 뭔가 복잡한 정보를 저장하거나 수정

파라미터(query) 단순히 특정 조건으로 데이터를 찾아오거나 삭제

쿼리 패스 바디

• path 패스
  • url 경로의 일부
  • 특정 자원 지칭 시 (id 등). 어떤 대상을 가리키는가.
  • 특정 리소스의 상세 조회, 수정, 삭제 시
  • ex) /api/user/123 id가 123번인 사람의 데이터 다룸
• query 쿼리
  • url 끝의 ? 뒤
  • 필터링, 정렬, 검색 조건. 어떻게 보여줄 것인가. 대상은 그대로인데 그 안에서 범위 좁히거나 모양 바꿈. 쿼리 파라미터가 없어도 api는 동작해야 하는 경우 많음
  • 필터링, 정렬, 검색, 페이지네이션
  • ex) /api/jandi/stats?start_date=2026-01-01..
• body 바디
  • http 요청 본문
  • 데이터 생성/수정 시 (복잡한 객체). 전달할 데이터 양이 많거나 복잡할 때
  • 외부로 데이터가 드러나지 않으며, 복잡한 객체 구조 전달 가능
  • POST, PATCH, PUT
  • 회원가입 정보, 프로필 수정 내용, 여러 설정 한꺼번에 보낼 때
  • ex) {"name": "고명주", "color_theme": "#fff"}

보통

| GET | path + query | 데이터 가져오기만 하므로 body 쓰지 않는 것이 원칙. 대상을 패스로 찍고, 조건을 쿼리로 걺. | | --- | --- | --- | | POST | body | 새로운 데이터를 저장해야 하므로 body 필수 | | PATCH/PUT | path + body | 어떤 대상(path)을 무슨 내용(body)로 수정할지 | | DELETE | path | 어떤 대상(path)을 지울지만 알면 됨 |

path parameters 패스 파라미터

url 경로 중간에 변수처럼 들어가는 값.

ex) /api/domain/{variable}