클라이언트에서 서버로 데이터 전송 (예시)
데이터를 전달하는 방식 2가지
(1) 쿼리 파라미터를 통한 데이터 전송
- 주로 GET에서 많이 사용
- 주로 정렬 필터 같은 것을 쓸 때 많이 사용 (검색할 때)
(2) 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH를 주로 사용
- 회원 가입, 상품 주문, 리소스 등록, 리소스 변경, ...
클라이언트에서 서버로 데이터를 전송하는 4가지 상황
(1) 정적 데이터 조회
- 이미지, 정적 텍스트 문서
- URI 경로만 넣으면 정적 데이터를 내려줌
- 일반적으로 쿼리 파라미터를 쓰지 않고, 리소스 경로만으로 조회함
- 조회에 GET을 사용
(2) 동적 데이터 조회
- 주로 검색, 게시판 목록에서 정렬 필터 (검색어)
- 조회에 GET을 사용, GET은 쿼리 파라미터를 사용해서 데이터를 전달
- 조회 조건을 줄여주는 필터 (검색어), 정렬하는 정렬 조건 등에 사용
- 검색할 때, 검색어를 전달하기 위해 query parameter를 사용함
(3) HTML Form을 통한 데이터 전송 (POST)
- 회원 가입, 상품 주문, 데이터 변경
- <form>
- html from의 submit 버튼을 누르면 웹 브라우저가 http 요청 메세지를 만든다.
- HTML Form은 GET 전송도 가능: GET으로 보내면 데이터를 쿼리 파라미터에 넣는다
- Contetn-Type: application/x-www-form-urlencoded:
- 바디에 쿼리 파라미터와 유사한 형식으로 보낸다 (key=value 형식)
- POST면 웹 브라우저가 데이터를 바디에 넣고, GET이면 쿼리 파라미터에 넣는다.
- 왜 encoded냐면 전송 데이터를 encoding하기 때문에 (한글 같은 것 넣으면 %EA%B9%.. 이렇게 인코딩함)
- Content-Type: multipart/form-data:
- 이미지와 같이 메세지 바디에 파일(바이너리 데이터)을 넣어야 할 때
- 다른 종류의 여러 파일과 폼의 내용을 함께 전송할 수 있음 (랜덤하게 part를 나눔, 그래서 multi part)
참고 HTML Form 전송은 GET, POST만 지원
(4) HTTP API를 통한 데이터 전송
- 회원 가입, 상품 주문, 데이터 변경
- 서버 to 서버, 앱 클라이언트, 웹 클라이언트 AJAX (Form 대신 자바 스크립트를 통한 통신에 사용)
- POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
- GET: 조회, 쿼리 파라미터로 데이터 전달
- Content-Type: application/json을 주로 사용 (거의 표준)
- 옛날에는 XML을 표준처럼 사용했지만... 이래저래 해서 요즘에는 JSON을 많이 쓴다
HTTP API 설계 예시
(1) HTTP API - 컬렉션
- POST 기반 등록
- /members는 컬렉션 (member 데이터를 집어넣는 ...)
- 회원 등록: /members 에 POST로 요청
- 회원 수정: /members/{id}에 PATCH, PUT, POST
- PUT/PATCH/POST의 차이를 고려해야 한다.
- 수정할 때는 PATCH로 하는 게 제일 좋다. 그치만 PUT을 쓸 수 있는 상황이면 써도 된다.
- 이것저것 애매해: POST 짱
- POST로 등록할 때:
- /members에 POST 요청을 보냄
- 신규 리소스를 식별할 수 있는 ID(리소스 URI)를 서버가 만들고 응답 메세지에 uri를 넣어 준다.
컬렉션: 서버가 관리하는 리소스 디렉토리, 서버가 리소스의 URI를 생성/관리, 예시에서는 /members
(2) HTTP API - 스토어
- PUT 기반 등록
- 예시: 파일 관리 시스템
- 파일 등록 /files/{filename} 에 PUT으로 요청
- PUT: 만약 filename이 없으면 생성, 있으면 덮어쓰기
- 파일 대량 등록 /files에 POST로 요청
- PUT으로 등록할 때:
- 클라이언트가 리소스의 URI를 알고 있어야 한다. 등록할 때: filename을 클라이언트가 들고 있어야 한다.
- 클라이언트가 생성되는 리소스의 URI를 다 알고, 관리한다는 뜻임 (!)
스토어: 클라이언트가 관리하는 리소스 저장소, 클라이언트가 리소스의 URI를 알고 관리, 예시에서는 /files
대부분 POST를 쓰고, PUT은 잘 안 쓴다.
- 파일 업로드 같은 것은 PUT을 쓸 수도 있기는 한데 보통 잘 안 쓴다.
(3) HTML FORM 사용
- 웹 페이지 회원 관리
- GET, POST만 지원
- AJAX 같은 기술로 해결할 수는 있긴 함
- 이 제약을 해결하기 위해 동사로 된 리소스 경로를 사용하기도 함 (Control URI)
- 회원 목록: GET
- 회원 등록 폼: 등록 버튼을 누르면 GET으로 페이지를 불러옴
- 회원 등록: 위에서 불러온 페이지에서 submit 버튼을 누르면 POST로 데이터를 보냄
- 회원 등록 폼이 /members/new를 보여줄 때, 회원 등록은 /members/new, /members 어느 쪽에 요청을 보내도 무관함
- (선생님이 선호하는 방식) /members/new에 보내는 것
- 이유: validation 문제가 있을 수 있음, POST를 /members에서 보내는 상황, 만약 회원 등록이 중단되었을 때 리프레쉬 하면 /members로 가게 되므로 폼 정보를 다 잃어버림
- 하지만 사람마다 호불호가 있다
- 회원 조회: /members/{id}에서 GET
- 회원 수정 폼: /members/{id}에 수정 버튼이 있다고 생각 -> 수정 폼도 리소스라고 생각 -> /members/{id}/edit을 GET으로 불러옴
- 회원 수정: /members/{id}/edit, 또는 /members/{id}에 POST로 데이터를 보냄
- 이때 URI 경로: edit를 넣을 것인가 말 것인가? -> 등록과 같은 문제
- 회원 삭제: /members/{id}/delete -> POST
- DELETE를 쓸 수 있으면 참 좋은데! 못 쓰니까 delete라는 control uri를 만들어서 POST 요청을 보낸다. 이 요청을 받으면 리소스를 지울 거라고 미리 설계해 둬야 한다.
컨트롤 URI
- 동사로 된 리소스 경로
- POST의 /new, /edit, /delete 같은 것
- 최대한 쓰지 말고, HTTP 메소드로 해결하기 어려운 경우에만 사용
참고하면 좋은 URI 설계 개념
링크: https://restfulapi.net/resource-naming/
