Portfolio

클라이언트에서 서버로 데이터 전송

데이터 전달 방식은 크게 2가지이다.

쿼리 파라미터를 통한 데이터 전송: GET, 주로 검색 시

메세지 바디를 통한 데이터 전송: POST, PUT, PATCH, 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 시

다음 4가지 상황을 예시로 살펴보자.

정적 데이터 조회

데이터 조회니까 GET 메서드를 사용하며, request-line에 조회하고 싶은 정적 데이터 URI를 적어 보낸다. 보통 이미지, 정적 text 문서를 조회할 때 사용하며, 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능하다.

동적 데이터 조회

동적 데이터는 주로 검색이나 게시판 목록에서 정렬 필터 등을 의미하며, 조회는 GET 메서드를 사용한다. 동적 데이터의 경우, 쿼리 파라미터를 사용해서 데이터를 전달한다. 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성하는 것이다.

HTML Form을 통한 데이터 전송

HTML의 form 태그에서 action과 method를 지정하여, 사용자가 작성한 내용(데이터)을 서버로 전송해준다. 여기서 method는 GET과 POST만 지원한다.

GET 전송의 경우 사용자가 작성한 내용을 조회할 때 사용되며, action에는 리소스 변경이 발생하지 않는 곳의 경로를 작성해주어야 한다. 사용자가 작성한 내용이 쿼리파라미터 형식으로 작성되어 조회되는 형태로 HTTP 메세지가 생성된다.

POST 전송의 경우 사용자가 작성한 내용을 저장하거나 변경할 때 사용되며, action에는 해당 리소스를 저장할 곳의 경로로 작성해주면 된다. 여기서 Content-Type은 전송 데이터를 url encoding 처리한다는 의미로 application/x-www-form-urlencoded를 사용하며, form의 내용을 메세지 바디에 담아 전송한다. 이 때, 메세지 바디에 담긴 데이터는 key=value 형태이다.

POST로 데이터를 전송할 때, 파일 업로드 같은 바이너리 데이터를 전송하거나 다른 종류의 여러 파일과 폼의 내용을 함께 전송할 때는 Content-Type를 multipart/form-data로 설정해주면 된다. 그러면 아래와 같은 HTTP 메세지가 생성된다.

HTTP API를 통한 데이터 전송

API를 통해 데이터를 전송할 때는 HTTP 메세지 바디에 원하는 데이터를 담아 보내면 된다. Content-Type은 전송하는 데이터의 타입을 적으면 되는데, 요즘에는 application/json을 주로 사용한다.

HTTP API를 통한 데이터 전송은 주로 서버 to 서버, 앱 클라이언트 (아이폰, 안드로이드), 웹 클라이언트 (HTML에서 form 전송 대신 자바스크립트를 통한 통신 - AJAX, React 같은 웹 클라이언트와 API 통신)에서 사용된다.

GET 메서드는 조회할 때 사용하며, 쿼리 파라미터로 데이터를 전달한다. POST, PUT, PATCH 메서드는 메세지 바디를 통해 데이터를 전송한다.

HTTP API 설계 예시

어떻게 API를 설계하면 좋을 지에 대해 3가지 예시로 확인해보자.

HTTP API - 컬렉션 (POST 기반 등록)

회원 관리 API를 예로 든다. 여기서는 회원이 리소스이니까, 리소스 URI를 /members 로 정했다.

회원 목록, 등록, 조회, 수정, 삭제 기능이 있을 때, 신규 회원을 등록하는 상황을 보자.

회원 등록은 POST 메서드를 사용하며, 클라이언트는 새로 등록될 리소스의 URI를 모른다. 따라서 POST /members 라고 서버에 보내면, 서버가 새로 등록된 리소스 URI를 생성해 알려준다. Location: /members/100

이렇게 서버가 관리하는 리소스 디렉토리를 컬렉션(Collection)이라고 한다. 컬렉션은 서버가 리소스의 URI를 생성하고 관리한다.

그럼 이 예시에서는 컬렉션이 무엇일까?

바로 /members가 되는 것이다.

HTTP API - 스토어 (PUT 기반 등록)

파일 관리 API를 예로 든다. 여기서는 파일이 리소스이니까, 리소스 URI를 /files로 정했다.

파일 목록, 조회, 등록, 삭제, 대량 등록 기능이 있을 때, 파일 등록하는 상황을 보자.

파일 등록은 기존에 파일이 없다면 현재 파일을 등록할 것이고, 기존에 파일이 있다면 기존 파일을 삭제하고 등록할 것이다. 그것이 PUT 메서드의 기능? 역할? 이기 때문이다.

원하는 파일을 등록하기 위해서는 클라이언트가 해당 리소스 URI를 알고 있어야 한다. 즉, 클라이언트가 직접 리소스의 URI를 지정하는 것이다. PUT /files/star.jpg

이렇게 클라이언트가 관리하는 리소스 저장소를 스토어(Store)라고 한다. 스토어는 클라이언트가 리소스의 URI를 알고 관리한다.

그럼 이 예시에서는 스토어가 무엇일까?

바로 /files가 되는 것이다.

HTML FORM 사용

순수 HTML의 경우에서, form 태그는 GET, POST 메서드만 지원하기 때문에 기존 URI 설계 방식으로는 한계가 있다.

이러한 한계를 해결하기 위해, 동사로 된 리소스 경로인 컨트롤 URI, 컨트롤러를 사용한다. 이는 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스를 실행한다.

ex) /members/{id}/delete

HTTP 메서드 활용