Today I Learn...
좋은 URI 설계란??
API URI 설계
예시 )
회원 목록 조회 : /get-member-list
회원 등록 : /create-member
회원 조회 : /get-member-by-id
회원 수정 : /update-member
회원 삭제 : /delete-member
위 방법이 좋은 URI 설계 방법일까??
정답은 NO!!!!!!!!!!!
URI 설계시 가장 중요한 것은 리소스 식별
리소스의 의미는???
회원을 등록하고 수정하고 조회하는게 리소스가 아니다
회원이라는 개념 자체가 바로 리소스다.
회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑!
회원목록 조회 /members
회원조회 /members/{id}
회원등록 /members/{id}
회원수정 /members/{id}
회원삭제 /members/{id}
도대체 어떻게 구분하지???
가장 중요한 것은 리소스를 식별하는 것이다.
리소스와 해당 리소스를 대상으로 하는 행위를 분리!!!
리소스 : 회원
행위 : 조회,등록,삭제,수정
리소스는 명사 / 행위는 동사
행위(메서드)는 어떻게 구분???
그 방법은 HTTP 메서드에 있다!
HTTP 메서드 종류
1) 주요 메서드
GET : 리소스 조회
POST : 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체, 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제
2) 기타 메서드
HEAD : GET과 동일하지만 메세지 부분을 제외하고 상태 줄과 헤더만 변환
OPTIONS : 대상 리소스에 대한 통신 기능 옵션을 설명(주로CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행
GET
리소스 조회
서버에 전달하고 싶은 데이터는 query를 통해 전달
메세지 바디를 사용해서 데이터를 전달 가능
POST
요청 데이터 처리
메세지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터 처리
주로 데이터 신규 리소스 등록, 프로세스 처리에 사용
PUT
- 리소스를 대체 없으면 생성
(즉 리소스가 존재하면 덮어쓰기 없으면 새로 만들기)- 클라이언트가 리소스식별
(클라이언트가 리소스 위치를 알고 URI 지정 : POST와 차이점)
PATCH
- 리소스 부분 변경
DELETE
- 리소스 삭제
HTTP 메서드 속성
- 안전(safe)
- 멱등(Idempotent)
- 캐시가능(Cacheable)
1. 안전(safe)
호출해도 리소스를 변경하지 않는다.
Q.계속해서 호출하여 로그가 쌓여 장애가 발생한다면??
A. 안전은 해당 리소스만 고려 나머지는 고려하지 않는다.
2. 멱등(Idempotent)
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다
- Q.재용청 중간에 다른 곳에서 리소스를 변경해버리면???
ex)
- 사용자1: GET -> username: A, age : 20
- 사용자2: PUT -> username: A, age : 30
- 사용자1: GET -> username; A, age : 30- A.멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
3. 캐시가능(Cacheable)
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시가능
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음
HTTP 메서드 활용
클라이언트에서 서버로 데이터 전송
• 정적 데이터 조회
• 동적 데이터 조회
• HTML Form을 통한 데이터 전송
• HTTP API를 통한 데이터 전송
정적 데이터 조회
이미지, 정적 텍스트 문서
조회는 GET 사용
정적 데이터는 일반적으로 쿼리 파라미터가 없어 리소스 경로로 단순하게 조회 가능
동적 데이터 조회
주로 검색, 게시판 목록에 정렬 필터(검색어)
조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
조회는 GET 사용
GET은 쿼리 파라미터 사용해서 데이터 전달
HTML FORM 데이터 전송
HTML Form 전송은 GET, POST만 지원
form의 내용을 메세지 바디를 통해서 전송(key=value)형태로 전송
GET방식인 경우 쿼리파라미터 형식으로 전송
content-type : multipart/form-data
파일 업로드 같은 바이너리 데이터 전송시 사용
다른 종류의 여러 파일과 폼의 내용 함께 전송 가능
HTTP API 데이터 전송
서버 to 서버 (백엔드 시스템 통신)
앱 클라이언트 (아이폰 ,안드로이드)
웹 클라이언트
HTML에서 FORM 전송 대신 자바스크립트를 통한 통신에 사용(AJAX)
ex)Reac,Vue.js같은 웹 클라이언트와 API 통신
POST,PUT,PATCH 메세지 바디를 통해 데이터 전송
GET 조회, 쿼리 파라미터로 데이터 전달
TEXT,XML,JSON 등등
정리
HTTP API - 컬랙션
POST 기반
서버가 리소스 URI 결정
HTTP API - 스토어
PUT 기반
클라이언트가 리소스 URI 결정
HTML FORM 사용
순수 HTML + HTML form 사용
GET, POST만 지원
컨트롤 URI
• GET, POST만 지원하므로 제약이 있음
• 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
• 예) POST의 /new, /edit, /delete가 컨트롤 URI
• HTTP 메서드로 해결하기 애매한 경우 사용(HTTP API 포함)
URI 설계 시 가장 중요한 것은?
리소스 식별
