API별 설계한 URI 확인

1. URI 설계 규칙

   • 정보의 자원은 URI로 표현

     • 자원은 동사보다는 명사를, 대문자보다는 소문자를 사용
     • 자원의 컬렉션 이름으로는 복수 명사를 사용 (ex, GET /users)

   • 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)로 표현

     PATCH /members/1
     

   • 자원의 표현은 JSON 포맷으로 데이터 전달

   • 슬래시 ****(/ )는 계층 관계를 나타내는데 사용

   • URI 마지막 문자로 슬래시(/ )를 포함하지 않음

   • 긴 URI경로의 경우 언더바 대신 하이픈(-)을 사용

   • 밑줄(_)은 URI에 사용하지 않음

   • URI 경로에는 소문자가 적합

   • 리소스간의 연관관계는 다음과 같이 표현

     • /리소스명/리소스 ID/관련된 다른 리소스명

2. HTTP Method 설계 규칙

   • 본래 목적에 맞게 HTTP Method를 사용

     METHOD	역할
     POST	POST를 통해 해당 리소스를 생성
     GET	GET를 통해 해당 리소스를 조회.
     PUT	PUT을 통해 해당 리소스 전체를 수정
     PATCH	PATCH을 통해 해당 리소스 일부를 수정
     DELETE	DELETE를 통해 리소스를 삭제

   • Non-RestFul : 이 프로젝트에서는 자원을 제거할때 DB에서 해당 row를 삭제하는 것이 아닌 status 칼럼의 값만 “ACTIVE”에서 “INACTIVE”로 변경 시켜주는 것이기 때문에 Delete Method 대신 Patch를 사용하였습니다.

3. HTTP 응답 상태코드 설계 규칙

   • 참고

     상태코드	설명
     200 (OK)	요청이 성공적으로 완료되었다는 의미
     301 (Permanently Moved)	요청한 리소스의 URI가 변경되었다는 의미
     400 (Bad Request)	잘못된 요청으로 인해 서버가 요청을 이해할 수 없다는 의미
     401 Unauthorized	해당 리소스에 유효한 인증 자격 증명이 없어 요청에 실패한 상태를 의미
     403 Forbidden	서버에 요청이 전달되었지만, 권한 때문에 거절된 상태를 의미
     500 (Internal Server Error)	서버에서 처리할 수 없는 내부 오류가 발생했다는 의미

   • Non-RestFul

     • 이 프로젝트에서는 예외 발생시에도 서버가 클라이언트에게 정상 응답(”200”)을 주도록 설계 하였습니다.
     • 그래서 HTTP Status 200 응답을 보내는 것으로 셋팅하였고, 응답 상태(status), 에러 코드(”code”), 에러 메시지(message) 필드로 예외 상황을 인지할 수 있게 설계하였습니다.
       • ex) status = “FAIL”
       • ex) code = “REQ_ERROR_INVALID_PHONE”
       • ex) message = “전화번호 형식 오류”
     • 리팩토링을 통해 모든 예외를 HTTP Status 규약에 맞게 변경할 예정입니다.