🎈 데이터 전송 방식
- 쿼리 파라미터
- 주로 필터, 검색어 (GET)
- requestBody
- 등록, 변경 등 (POST, PUT, PATCH)
🎈 데이터 전송 상황
- 정적 데이터 조회
- 쿼리 파라미터 등 추가적인 데이터 없이 uri 에 요청해서 리소스를 받음
- 동적 데이터 조회
- 쿼리 파라미터를 사용해서 조회를 위한 데이터를 전송
- HTML Form 데이터 전송
form태그를 통해 쿼리 스트링을 자동으로 생성해서 전송- GET/POST 요청만 가능
- GET 요청 시 쿼리 스트링이 url 뒤에 붙어서 전송
- POST 요청 시
application/x-www-form-urlencoded컨텐츠 타입으로 생성되어 requestBody에 전송됨 - 파일 전송 시
multipart/form-data컨텐츠 타입으로 생성되어 전송
- HTTP API 데이터 전송
- GET 이면 쿼리 파라미터, 다른 메소드는 requestBody
- requestBody는 JSON, TEXT, XML 등의 형식으로 데이터 전송
application/json타입이 requestBody의 거의 표준으로 사용됨
🎈 API 설계 예시 1 (회원 관리)
- 회원 목록 조회 :
GET /members - 회원 정보 조회 :
GET /members/{id} - 회원 등록 :
POST /members - 회원 삭제 :
DELETE /members/{id} - 회원 수정 :
PATCH, PUT, POST /members/{id}PUT은 수정하지 않을 필드 정보들도 다 보내야 한다.
회원 등록 시 서버가 /members/100 과 같이 리소스 URI 를 생성하고 관리한다.
/members 와 같이 서버가 관리하는 리소스 디렉토리를 컬렉션 이라고 한다.
🎈 API 설계 예시 2 (파일 관리)
- 파일 목록 :
GET /files - 파일 조회 :
GET /files/{filename} - 파일 등록 :
POST /files/{filename} - 파일 삭제 :
DELETE /files/{filename} - 파일 수정 :
PUT /files/{filename} - 대량 등록 :
POST /files
/files/1.jpg에서 파일 이름을 클라이언트가 직접 지정하고 관리한다.
/files 와 같이 클라이언트가 리소스 URI 를 입력하고 관리하는 디렉토리를 스토어 라고 한다
velog 도 이거 아닐까..?
🎈 설계 개념
- 문서 : 파일 하나, 회원 하나 등 단일 객체 조회
- 컬렉션 : 서버가 알아서 리소스를 생성하고 관리하는 디렉터리
- 스토어 : 클라이언트가 리소스를 생성하고 수정할 수 있는 디렉터리
- 컨트롤 URI : 최대한 리소스와 메소드 조합을 바탕으로 URI 를 설계하고, 그걸로 안될 때에는 컨트롤 URI (동사)를 사용
