본문 바로가기

study/HTTP

HTTP 웹 기본 지식(5) - HTTP 메서드 활용

이 글은 인프런 김영한 님의 강의 모든 개발자를 위한 HTTP 웹 기본 지식을 듣고 정리하는 글입니다.

 

클라이언트에서 서버로 데이터 전송하는 경우를 살펴보자.

 

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

  • 쿼리 파라미터를 통한 데이터를 전송 - GET에서 사용하고, 주로 정렬 필터 등에서 많이 사용한다.
  • 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH 등에서 사용하고, 회원가입, 상품 주문, 리소스 등록, 리소스 변경 등에서 사용한다.

 

쿼리 파라미터를 사용하는 경우를 두 상황으로 나눠서 보자.

  • 정적 데이터 조회하는 경우
    • 쿼리 파라미터를 사용하지 않는 경우이다.
    • 이미지를 요청한다, 그냥 uri 정도만 있어도 된다. 따로 필요한 파라미터는 없다.
    • 보통 정적 데이터는 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능하다.
  • 동적 데이터 조회하는 경우
    • 동적 데이터를 조회할 때는 쿼리 파라미터를 사용한다.
    • 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성한다.
    • 주로 검색, 게시판 목록에서 정렬 필터할 사용하거나
    • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용한다.
    • 조회는 get 사용한다.

 

이번에는 HTML Form 통한 데이터 전송, body 전송을 보자.

  • HTML의 form 태그를 사용해서 데이터를 전송하는 경우, POST 통신이 사용된다.
  • 보통 content-type은 "application/x-www-form-urlencoded"(기본 인코딩 타입)이고 form의 내용을 body에 key=value 형태로 데이터가 전달된다. 전송 데이터는 url encoding 처리해서 보낸다.(abc김 -> abc%EA%B9%80)
  • form을 이용해 get 전송을 할 수는 있지만, form의 내용을 쿼리 파라미터로 넣어버린다. 굳이 써야 한다면, 조회용으로 사용해야 한다.
  • HTML Form 전송에서 content-type(인코딩 타입) 중에 "multipart/form-data"란 것이 있다. 텍스트가 아닌 바이트로 되어 있는 데이터를 전송할 때 사용한다.(그래서 이름이 multipart) 이 때는 바디에 데이터를 담을 때 "boundary"라는 것이 설정 되어 이 "boundary"를 통해 데이터를 구분해서 보낸다. 예를 들어 content-type에 "boundary=----x"라는 설정을 추가하면 "----x"로 데이터를 구분해서 보낸다.

 

boundaryt 사용 예시.

  • HTML FORM 전송은 GET, POST만 지원된다.

HTTP API 통한 데이터 전송을 살펴보자.

  • 서버에서 바로 HTTP 메시지를 만들어서 전송하거나
  • 서버끼리 백엔드 통신을 하거나
  • 모바일 앱 클라이언트가 통신을 하거나
  • 웹 클라이언트가 통신을 하거나 등등의 많은 경우가 있다.
  • 보통의 통신은 content-type을 application/json으로 한다.(사실상 표준)
  • POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송
  • GET: 쿼리 파라미터로 데이터 전달.

HTTP API 설계 예시를 보자.

 

HTTP API - 컬렉션(컬렉션 참고 링크: https://meetup.toast.com/posts/92)

POST 기반 등록의 회원 관리 API를 예로 들어보자.

  • 리소스 중심으로 URI를 제작할 것이다.
    • 회원 목록 /members -> GET
    • 회원 등록 /members -> POST
    • 회원 조회 /members/{id} -> GET
    • 회원 수정 /members/{id} -> PATCH, PUT, POST
    • 회원 삭제 /members/{id} -> DELETE
    • PUT은 일부분 데이터만 보내서 수정하는 것이 아닌, 모든 속성에 대한 정보를 담고 수정 데이터를 보낸다. 대게 회원 정보 같은 경우라면, 데이터가 많기 때문에 사용하지 않을 것이고, 게시글 같은 경우에는 데이터가 적기 때문에 PUT을 사용할 수 있다.
    • PATCH는 수정할 일부분 데이터만 보낸다.
    • 만약 어떤 메서드를 사용할지 애매하다? -> POST를 사용한다.
  • 클라이언트가 새로운 회원을 등록하려고 한다면, 등록될 리소스의 URI는 모른다. 등록하는 URI는 아는데, 등록 후의 URI는 모른다. POST 기반의 등록이기 때문이다.
  • 서버가 리소스의 URI를 결정하고 만들어준다. 서버가 결정한다. -> PUT 기반 등록과의 차이점.
  • 이렇게 서버가 관리하는 리소스 디렉토리를 컬렉션이라고 한다. 여기서는 /members
  • 서버가 리소스의 URI를 생성하고 관리하게 된다.

HTTP API - store -> 이번에는 PUT 기반 등록(스토어라고 한다.)의 파일 관리 시스템을 보자.

  • 파일 목록 /files -> GET
  • 파일 조회 /files/{filename} -> GET
  • 파일 등록 /files/{filename} -> PUT
  • 파일을 등록하는 경우, 클라이언트는 파일 이름을 알고 있을 것이다.
  • 이런 파일 관리 시스템의 경우, put 적절하다. 이미 존재하는 경우, 덮어 쓸 수도 있어야 하기 때문에.
  • 파일 삭제 /files/{filename} -> DELETE
  • 파일 대량 등록 /files -> POST
  • PUT 기반 등록의 경우 POST 기능은 임의로 정해도 된다. 여기서는 대량 등록으로 사용.
  • PUT 기반으로 신규 자원을 등록하는 경우, 클라이언트가 리소스 URI를 알고 있어야 한다.(파일 등록 /files/{filename} -> PUT)
  • 이렇게 클라이언트 관리하는 리소스 저장소를 스토어라 한다.
  • 클라이언트가 리소스의 URI를 알고 관리한다.
  • 여기서 스토어는 /files

이렇게 HTTP api 등록은, POST 기반, PUT 기반의 등록이 있는데, 대개는 POST 기반의 등록을 사용한다.

 

마지막으로 HTML FORM 사용하여 등록하는 경우를 보자.

  • HTML FORM GET, POST 지원한다.(순수한 HTML에서는)
  • AJAX 같은 기술을 사용해서 다른 메서드들을 사용할 수 있긴 하다.
  • 회원 목록 /members -> get
  • 회원 등록 조회 /members/new -> get
  • 회원 등록(저장 버튼을 누를 )  "/members/new"(uri는 같지만, 메서드는 다르니까 구부 가능) 또는 "/members"-> POST
  • 회원 조회 /members/{id} -> Get
  • 회원 수정 조회 /members/{id}/edit -> get
  • 회원 수정 /members/{id}/edit 또는 /members/{id} -> POST
  • 회원 삭제 /members/{id}/delete -> POST(DELETE를 못쓰니까)
  • HTML FORM GET, POST 지원한다. 그래서 컨트롤 URI 사용해야 한다.
  • GET과 POST만 지원하는 제약을 해결하기 위해 동사로 리소스 경로를 사용한다.
  • POST "/new", "/edit", "/delete" 컨트롤 URI다.
  • HTTP 메서드로 해결하기 애매한 경우, 컨트롤 URI 사용하면 된다.
  • 컨트롤 URI 동사를 사용해야 한다.

정리

  • HTTP API - 컬렉션 - POST 기반 등록. 서버가 리소스 URI 결정.
  • HTTP API - 스토어 - PUT 기반 등록. 클라이언트가 리소스 URI 결정.
  • HTML FORM 사용 - 순수 HTML + HTML FORM 사용. GET, POST만 지원.

참고하면 좋은 URI 설계 개념(출처: https://restfulapi.net/resource-naming )

리소스를 구분하는 개념들.

  • 문서(document) - 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 테이블의 row)
  • 컬렉션(collection) - 서버가 관리하는 리소스 디렉토리. 서버가 리소스의 URI를 생성하고 관리.
  • 스토어(store) - 클라이언트가 관리하는 자원 저장소. 클라이언트가 리소스의 URI를 알고 관리.
  • 컨트롤러(controller), 컨트롤 URI - 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행 동사를 직접 사용.
    • 예) /members/{id}/delete