1. Rest Api 구성
Rest Api는 다음과 같이 3가지로 구성되어 있다.
- 자원 (URI)
- 행위 (Method)
- 내용 (Message Pay Load)
2. Rest Api 중심 규칙
- URI는 정보의 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP Method(GET,POST,PUT,DELETE)로 표현한다.
2-1 URI는 정보의 자원을 표현해야 한다.
- 리소스명은 동사보다 명사를 사용한다.
#예시 1 - 유저 조회
#나쁨 GET /getUsers/1 #좋음 GET /users/1
#예시 2 - 유저 생성
#나쁨 GET /createUsers/1 #좋음 POST /users/1
#예시 3 - 유저 수정
#나쁨 GET /updateUsers/1 #좋음 PUT /users/1
#예시 4 - 유저 삭제
#나쁨 GET /deleteUsers/1 #좋음 DELETE /users/1
- URI는 자원을 표현하고 행위는 HTTP METHOD를 통해서 표현하고 구분하는 것이 바람직하다.
- 짧고 간결한 URI로 다양한 표현이 가능해진다.
3. HTTP METHOD
- 주로 5가지 Method로 구현한다.
- GET - 조회
- POST - 생성
- PUT - 리소스 전체 교체
- PATCH - 리소스 일부 수정
- DELETE - 삭제
4. 응답코드
- 클라이언트에서 HTTP의 상태 코드를 확인하여 요청작업이 성공 여부를 확인할 수 있다.
- 2xx 코드는 성공코드이므로 어플리케이션이 계속 작업을 이어나가도 좋다는 의미
- 4xx 코드는 실패코드로 원인에 따라 조치를 취해야 함
- 5xx 코드는 서버 오류로 인하여 요청을 실행할 수 없다는 의미로 API응답에서 웬만하면 발생해서는 안되는 코드. 주로 개발자 실수로 발생한다고 한다.
5. API 문제사항 자체 체크
- 모든 요청을 POST로 처리하는지, PUT, DELETE 등 다른 메소드를 활용하는지
- URI에 동사가 포함되어 있는지
- 응답 메타 데이터가 Header가 아니라 Body에 포함되어 있는지
- 적절한 응답코드를 반환하는지, 5xx 응답코드를 반환하고 있지는 않은지
Rest Api를 설계할 때 항상 자체 점검리스트를 들고다니며 더욱 Restful한 API를 만들기 위해 노력해야겠다.
엉덩이가 무거운 개발자