HTTP 웹 지식 - HTTP 메서드 활용

📌 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의 듣고 정리

 

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

클라이언트에서 서버로 데이터 전달하는 방식은 크게 2가지 이다.

 

1. 전달방식 

• 쿼리 파라미터를 통한 데이터 전송
  • GET
  • 주로 정렬 필터(검색어)

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

        

2. 상황

• 정적 데이터 조회 : 이미지, 정적 텍스트 문서
  • 조회는 GET 사용
  • 정적 데이터는 일반적으로 쿼리 파라미터 사용없이 리소스 경로만으로 조회 가능
• 동적 데이터 조회 : 주로 검색, 게시판 목록에서 정렬 필터(검색어)
  • 쿼리 파라미터를 사용, 이를 서버에서 key-value로 꺼내어 사용
  • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
  • 조회는 GET
  • GET은 쿼리 파라미터를 사용해서 데이터를 전달
• HTML Form을 통한 데이터 전송 : 회원가입, 상품주문, 데이터 변경
  • HTML의 Form 태그를 통해 데이터를 전송하는 방식으로 form태그의 submit을 하게 되면 웹 브라우저에서 form의 데이터를 읽어 HTTP 메시지를 생성해준다. (Type = application/x-www-form-urlencoded 사용)
  • (왜 url encoded 인가? url로 사용할 수 없는 문자를 사용할 수 있도록 인코딩해서 넘겨주기 때문)

  

    
    
    
    
  
<form action="/save" method="post">
	<input type="text" name="username"/>
    <input type="text" name="age"/>
    <button type="submit">전송</button>
</form>

POST /save HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

username=kim&age=20

• form에서 method를 get으로 지정하게 되면 GET은 보통 메시지 바디를 사용하지 않기에 쿼리 파라미터로 바꿔서 HTTP 메시지를 만든다 (GET의 메시지 바디를 지원하지 않는 곳들이 존재한다. 그리고 GET은 조회용)

GET /members?username=kim&age=20 HTTP/1.1
Host: localhost:8080

• multipart/form-data : 파일 업로드와 같은 바이너리 데이터 전송할 때 사용하는 Content-Type

  

    
    
    
    
  
<form action="/save" method="post" enctype="multipart/form-data">
    <input type="text" name="username"/>
    <input type="text" name="age"/>
    <input type="file" name="file1" />
    <button type="submit">전송</button>
</form>

        웹 브라우저가 생성한 HTTP 메시지 : boundary 기준으로 자름 (랜덤지정)

        multipart라는 이름은 이런식으로 다른 종류의 여러 파일과 form 내용을 함께 전송이 가능해 multipart이다.

POST /save HTTP/1.1
Host: localhost:8080
Content-Type: multipart/form-data; boundary=---XXX

------XXX
Content-Disposition: form-data; name="username"

kim
------XXX
Content-Disposition: form-data; name="age"

20
------XXX
Content-Disposition: form-data; name="file1"; filename="intro.png"
Content-Type: image/png

109238a9o0p3eqwokjasd09ou3oirjwoe9u34ouidf...   <= 이미지에 대한 바이트 정보
------XXX--

+ 참고: HTML Form은 GET과 POST만 지원

 

• HTTP API를 통한 데이터 전송 : 서버 to 서버, 앱 클라이언트, 웹 클라이언트(AJAX방식)
  • HTML Form을 쓰지 않고 데이터를 전송하는 경우 대부분
  • POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송
  • GET : 조회, 쿼리 파라미터로 데이터 전달
  • Content-Type: application/json을 주로 사용하는 데 사실상 표준처럼 사용

 

📍HTTP API 설계 예시

 

HTTP API를 크게 두가지로 분류하여 설계할 수 있는데 하나는 POST기반의 등록 방식 "컬렉션",  다른 하나는 PUT기반의 등록방식 "스토어"다. POST와 PUT을 이용해 새로운 정보를 저장할 때 서로 다른 특징이 있는데 이를 잘 정리해야한다.

 

* HTTP API - 컬렉션

    - POST 기반 등록으로 설명

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

    - 클라이언트는 등록될 리소스 URI를 모른다 > 서버가 데이터 받아 새로 등록된 리소스 URI를 생성 (ex. /members/100)

    - 이러한 형식을 컬렉션(Collection) 이라고 한다. 

      서버가 관리하는 리소스 디렉토리를 말하며 서버가 리소스 URI를 생성하고 관리한다. 여기서는 /members가 컬렉션!

    - 일반적으로 이 방식을 많이 사용

 

    

* HTTP API - 스토어

    - PUT 기반 등록으로 설명

파일 목록 조회	/files	GET
파일 등록	/files/{filename}	PUT (업로드할 파일 이름을 알고 있기 때문, 동일한 이름 있으면 대체 없으면 생성)
파일 단건 조회	/files/{filename}	GET
파일 삭제	/files/{filename}	DELETE
파일 대량 등록	/files	POST (등록에 PUT을 사용했으므로 POST는 필요에 따라 임의 지정)

    - 클라이언트는 등록될 리소스 URI를 알아야 한다. > 클라이언트가 직접 리소스 URI를 지정해 관리

    - 이러한 형식을 스토어(Store) 라고 한다. 

      클라이언트가 관리하는 리소스 저장소를 말하며 클라이언트가 리소스 URI를 알고 관리. 여기서는 /files가 스토어!

 

 

* HTML FORM 사용

    - HTML FORM은 GET, POST만 지원 (AJAX 같은 기술을 사용해 이런 제약 해결 가능)

    - 여기서는 순수 HTML + HTML FORM 이야기할 것으로 GET과 POST만 지원하므로 제약이 있다. 

회원 목록 조회	/members	GET
회원 등록 폼	/members/new	GET (등록 폼을 조회, submit 하면 아래 회원 등록 POST로)
회원 등록	/members /members/new	POST (두가지 선택 가능, 컬렉션처럼 리소스 기준 or 등록 폼을 따르는)
회원 단건 조회	/members/{id}	GET
회원 수정 폼	/members/{id}/edit	GET (수정 폼 및 데이터를 조회, submit 하면 아래 회원 수정 POST로)
회원 수정	/members/{id} /members/{id}/edit	POST
회원 삭제	/members/{id}/delete	POST (/members/{id} 로 POST를 사용할 수 없으면 컨트롤 URI를 사용)

    - 컨트롤 URI

      GET, POST만 지원하므로 제약이 있어 이걸 해결하기 위해, "동사"로 된 리소스 경로를 사용

      POST의 /new, /edit, /delete 가 컨트롤 URI에 해당한다. 

      제약 해결 뿐만 아니라 HTTP 메서드로 해결하기 애매한 경우에도 사용한다(HTTP API 포함).
      최대한 리소스개념을 사용하되 그게 힘들 경우 대체제로 사용!

 

📍참고하면 좋은 URI 설계 개념

* 문서 (document)

• 단일 개념 (파일 하나, 객체 인스턴스, 데이터베이스 row)
• ex) /members/100, /files.star.jpg

* 컬렉션 (collection)

• 서버가 관리하는 리소스 디렉토리
• 서버가 리소스의 URI를 생성하고 관리
• ex) /members

* 스토어 (store)

• 클라이언트가 관리하는 리소스 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• ex) /files

* 컨트롤러 (controller), 컨트롤 URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• ex) /members/{id}/delete

REST API - URL Naming Conventions