0. HTTP API
목표
회원 정보 관리 API를 만들어라.
• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제
가장 중요한 것은 리소스 식별
회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)
• 회원 목록 조회 /members
리소스와 행위을 분리
- 리소스: 회원
- 행위: 조회, 등록, 삭제, 변경
- 리소스는 명사, 행위는 동사
1. HTTP 메서드 종류
• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
- 메시지 바디를 통해 서버로 요청 데이터 전달
- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
- 다른 메서드로 처리하기 애매한 경우 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
- 리소스가 있으면 대체
- 리소스가 없으면 생성
- 클라이언트가 리소스를 식별
- 클라이언트가 리소스 위치를 알고 URI 지정
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
• CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
2. HTTP 메서드의 속성
• 안전(Safe Methods)
- 호출해도 리소스를 변경하지 않는다.
• 멱등(Idempotent Methods)
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
- GET, PUT, DELETE 는 멱등 메서드
- POST 는 멱등이 아니다. 여러번 호출하면 같은 결제가 중복해서 발생 가능
- 활용) 자동 복구 메커니즘, 서버가 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해
도 되는가 판단시
- 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.
• 캐시가능(Cacheable Methods)
- GET, HEAD, POST, PATCH 캐시가능
- 실제로는 GET, HEAD 정도만 캐시로 사용
3. 클라이언트에서 서버로 데이터 전송
데이터 전달 방식
1) 쿼리 파라미터를 통한 데이터 전송
• GET
• 주로 정렬 필터(검색어)
2) 메시지 바디를 통한 데이터 전송
• POST, PUT, PATCH
• 회원 가입, 상품 주문, 리소스 등록, 리소스 변경
4가지 상황
• 정적 데이터 조회
- 이미지, 정적 텍스트 문서
• 동적 데이터 조회
- 주로 검색, 게시판 목록에서 정렬 필터(검색어)
- 쿼리 파라미터 사용
• HTML Form을 통한 데이터 전송
- 회원 가입, 상품 주문, 데이터 변경
- GET, POST 만 지원
- Content-Type: application/x-www-form-urlencoded 사용
--> 전송 데이터를 url encoding 처리
- Content-Type: multipart/form-data
--> 파일 업로드 같은 바이너리 데이터 전송시 사용
• HTTP API를 통한 데이터 전송
- 회원 가입, 상품 주문, 데이터 변경
- 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)
- Content-Type: application/json을 주로 사용 (사실상 표준)
--> TEXT, XML, JSON 등등
4. HTTP API 설계 예시
• HTTP API - 컬렉션
- POST 기반 등록
- 예) 회원 관리 API 제공
• HTTP API - 스토어
- PUT 기반 등록
- 예) 정적 컨텐츠 관리, 원격 파일 관리
• HTML FORM 사용
- 웹 페이지 회원 관리
- GET, POST만 지원
POST 기반 등록시의 설계
5. URI 설계 개념 - good practices
• 문서(document)
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- 예) /members/100, /files/star.jpg
• 컬렉션(collection)
- 서버가 관리하는 리소스 디렉터리
- 서버가 리소스의 URI를 생성하고 관리
- 예) /members
• 스토어(store)
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 예) /files
• 컨트롤러(controller), 컨트롤 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용
- 예) /members/{id}/delete
** 참고: https://restfulapi.net/resource-naming
Reference
인프런 강의 - 김영한 HTTP 기본 지식