Jay

API 설계를 해보자. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 아래의 좋지 않은 설계를 보자. 회원 목록 조회 / read-member-list 회원 조회 / read-member-by-id 회원 등록 / creadte-member 회원 수정 / update-member 회원 삭제 / delete-member 가장 중요한 것은 리소스 식별이다. API URI 고민 리소스의 의미는? 회원을 등록하고 수정하고 조회하는게 리소스는 아님 회원이라는 개념 자체가 바로 리소스 리소스를 어떻게 식별할까 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식별하자. 회원 리소스를 URI에 매핑 리소스 식별, URI 계층 구조 활용(URI 설계는 리소스 식별 + URI 계층 구조로 ..

URI 리소스를 식별하는 통합된 방법 "URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다." 참고 : https://www.ietf.org/rfc/rfc3986.txt URL(리소스의 위치) / URN(리소스의 이름) urn은 이름을 부여한다.(리소스 찾기 어려움) - 거의 url만 쓴다. URI Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL : Uniform Resource Locator URN: Uniform Resource Name URL, URn URL - Locator : 리소스가 있는 위치를 지정 URN - Name: 리소..