HTTP 메서드 활용

• 목차
  • 1.클라이언트에서 서버로 데이터 전송
  • 2.HTTP API 설계 예시

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

데이터 전달 방식은 크게 2가지로 나눌 수 있다.

• 쿼리 파라미터를 통한 데이터 전송 : GET, 주로 정렬 필터(검색어)
• 메시지 바디를 통한 데이터전송 : POST, PUT, PATCH/ 회원가입, 상품 주문, 리소스 등록과 변경 등

클라이언트에서 서버로 데이터 전송할때 4가지 상황으로 분류할 수 있다.

• 정적 데이터 조회 : 이미지, 정적 텍스트 문서
• 동적 데이터 조회 : 주로 검색, 게시판 목록에서 정렬필터
• HTML Form을 통한 데이터 전송 : 회원가입, 상품주문, 데이터 변경
• HTTP API를 통한 데이터 전송 : 회원가입, 상품주문, 데이터변경, 서버 to 서버, Ajax

정적 데이터 조회는 단순하게 이미지나 텍스트를 호출해서 데이터를 받는 형태이다. GET 메소드를 사용하고 정보로 url만 있으면 되는 단순한 형태이다.
동적 데이터 조회는 정적 데이터 조회보다 쿼리 파라미터를 사용하여 특정 데이터를 불러온다. 어째든 조회이기 때문에 GET 메소드를 사용한다.
HTML Form으로 데이터를 전송하는 경우, submit시 POST로 전송한다. 회원가입이나 상품 주문, 데이터 변경 등 데이터를 입력하거나 변경할때 사용한다. 그리고 Content-Type으로 application/x-www-form-urlencoded를 사용한다. from의 내용을 메시지 바디를 통해서 전송하는데 이는 key=value 쌍, 쿼리 파라미터 형식으로 전송하고 전송 데이터를 url encoding 처리를 한다. (예: abc김을 abc%EA%B9%80) HTML Form은 GET 전송도 가능하다. 그러나 POST와 GET 방식 이외의 PUT이나 PATCH 등의 방식은 지원하지 않는다. 그 외에 Content-Type이라고 multipart/form-data도 있는데 파일 업로드 같이 바이너리 데이터 전송할 때 사용한다. 다른 종류의 여러 파일과 폼의 내용 함게 전송이 가능하다.
HTTP API로 데이터를 전송하는 방식은 서버와 서버끼리 시스템 통신하는 경우, 앱 클라이언트인 아이폰이나 안드로이드 통신하는 경우, 웹 클라이언트에 HTML에서 자바스크립트로 통신하는 AJAX에서 쓰인다. 앞선 HTML Form과 달리 GET,POST는 물로 PUT과 PATCH도 지원한다. POST, PUT, PATCH로 메시지 바디를 통해 데이터를 전송하고 GET으로 조회할때 쓰며 쿼리 파라미터로 데이터를 전달한다. Content-Type으로 application/json을 주로 사용하는데 사실상 표준이 됐다.

2. HTTP API 설계 예시

회원 관리 시스템을 예시로 설계를 생각해보자. 이전 글에 API는 리소스를 기준으로 설계해야한다고 배웠다. 거기에 앞서 서술한 HTTP 메소드의 용도를 생각하고 짝지으면 다음과 같이 된다.

• 회원 목록 /members -> GET
• 회원 등록 /members -> POST
• 회원 조회 /members/{id} -> GET
• 회원 수정 /members/{id} -> PATCH, PUT, POST
• 회원 삭제 /members/{id} -> DELETE

회원 목록 GET은 간단하니 넘어가고 POST 신규 자원 등록 특징을 보자. POST의 경우, 클라이언트는 등록될 리소스의 URI를 모른다. 그리고 서버가 알아서 새로 등록된 리소스 URI를 생성해준다. 이때 서버가 관리하는 리소스 디렉토리를 컬렉션(Collection)이라고 한다. 여기서 컬렉션은 /members이다.
그리고 유의하게 봐야할 것이 회원 수정이다. 보통 회원 수정은 부분만 수정하므로 PATCH를 쓰는게 적합하다. PUT을 쓸 수도 있겠지만 매번 수정하는 부분 외 내용을 똑같이 입력해 보내야 하므로 쉽지 않다. 이런 PUT을 쓰는 것은 게시판 글을 수정할 때이다. 그리고 아래와 같이 파일 관리 시스템의 파일 등록할 때도 쓸 수 있다.

• 파일 목록 /files -> GET
• 파일 조회 /files/{filename} -> GET
• 파일 등록 /files/{filename} -> PUT
• 파일 삭제 /files/{filename} -> DELETE
• 파일 대량 등록 /files -> POST

파일을 등록할 때 완전히 덮어 쓰는 것이 가능하므로 PUT을 쓸 수 있다. 대신 POST는 /members만 쓰고 보내면 서버가 알아서 URI를 생성해 줬지만 PUT은 클라이언트가 리소스 URI를 알고 있어야 한다. 그래서 회원 등록과 달리 파일 등록은 file/{filename} 붙여 지정해야한다. 클라이언트가 리소스의 URI를 알고 관리하는 이런 방식을 스토어(Store)라고 한다.

이번에는 HTML FORM을 사용하는 경우를 생각해보자. HTML FORM은 GET과 POST만 사용할 수 있으므로 제약이 따른다. 제약이 맞춰 설계하면 이렇게 된다.

• 회원 목록 /members -> GET
• 회원 등록 폼 /members/new -> GET
• 회원 등록 /members/new, /members -> POST
• 회원 조회 /members/{id} -> GET
• 회원 수정 폼 /members/{id}/edit -> GET
• 회원 수정 /members/{id}/edit, /members/{id} -> POST
• 회원 삭제 /members/{id}/delete -> POST

GET, POST만 지원하는 제약이 있으므로 동사로 된 리소스 경로를 사용해서 해결한다. POST의 /new, /edit, /delete가 그 컨트롤 URI이이다. 컨트롤 URI는 HTTP 메서드로 해결하기 애매한 경우 사용한다.(HTTP API 포함)