HTTP 메서드1(HTTP API를 만들어보자)

 

웹 사이트에서 회원 정보 관리 API를 만들 때 저것들을 요구사항에 넣는다고 해보면,

그러면 이런 형식으로 개발을 할텐데요.

 

과연 위에 있는 URI 설계법이 좋은 설계법일까?

 

가장 중요한 것은 리소스를 식별하는 것입니다. 회원을 등록하고 수정하고 조회하는게 리소스가 아니고 회원이라는 개념 자체가 바로 리소스이다. 

 

리소스는 어떻게 식별하는게 좋을까?

- 회원을 등록하고 수정하고 조회하는 것을 모두 배제한다.

- 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑

 

 

리소스를 식별하기 좋게  API URI 설계

- 회원 목록 조회 /members

- 회원 조회 /members{id}

- 회원 등록/members{id}

- 회원 수정/members{id}

- 회원 삭제/members{id}

- 참고: 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용 권장(member->members)

 

 

리소스와 행위를 분리

가장 중요한 것은 리소스 자체를 식별하는 것!

- URI는 리소스만 식별!

- 리소스와 해당 리소스를 대상으로 하는 행위를 분리 예) 미네랄과 미네랄 캐는 것을 분리

           - 리소스: 회원

           - 행위: 조회, 등록, 삭제, 변경

- 리소스는 명사, 행위는 동사(미네랄을 캐라)

반응형