[WEB/HTTP] 05. HTTP 메서드 활용

 

 

이 글은 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식" 을 학습하며 정리한 내용입니다.

저처럼 HTTP를 알고 싶거나, 겉핥기로 알고 있는 분들에게 위 강의를 추천합니다.

 

정리한 내용 중 틀린 내용이 있으면 지적해주시면 수정하겠습니다.

---

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

• 쿼리 파라미터(쿼리 스트링)를 통한 데이터 전송

GET 방식

정렬 필터(검색어)

 

• 메시지 바디를 통한 데이터 전송

POST, PUT, PATCHGET도 메시지 바디를 사용할 수 있지만 지원하지 않는 서버가 많기 때문에 권장 X

---

• 정적 데이터 조회

이미지, 정적 텍스트 문서

쿼리 파라미터(쿼리 스트링)가 필요하지 않음, 리소스 경로로 단순하게 조회 가능

예) GET /static/star.jpg

 

• 동적 데이터 조회

검색, 게시판 목록에서 정렬 필터(검색어) 등

쿼리 파라미터(쿼리 스트링) 사용하여 조회

예) GET /search?q=hello&hi=ko

 

• HTML Form을 이용한 데이터 전송

회원 가입, 상품 주문, 데이터 변경

 

POST 방식 - 저장 = content-Type: application/x-www-form-urlencoded

POST 요청 시 content-Type이 위와 같이 지정 및 전송 데이터를 인코딩 처리(한글 인코딩)

form 태그 안의 데이터는 메시지 바디에 쿼리 스트링과 유사한 형식으로 작성되어 전달 username=kim&age=20

 

GET방식 - 조회 = form 태그에서 GET 요청도 할 수 있음

GET 요청 시  동적 데이터 조회처럼 쿼리 파라미터(쿼리 스트링)를 포함하여 HTTP 메시지를 생성 후 요청

GET /search?username=kim&age=20 

 

GET은 조회에서만 사용하니 리소스 변경이 발생하는 곳에서 사용하지 않도록 주의 !

 

multipart/form-data = form 태그 속성으로 enctype="multipart/form-data"를 지정하여 전송

Content-Type: multipart-form/data; boundary=-----XXX

form 내 데이터들을 구분하여 전송하는 형태

파일 업로드와 같은 바이너리 데이터 전송 시 사용

다른 종류의 여러 파일과 폼의 내용을 함께 전송이 가능해서 multipart

 

 

• HTTP API를 통한 데이터 전송

서버 to 서버(백엔드 시스템 통신), 앱 클라이언트, 웹 클라이언트(AJAX) 등에서 사용

POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송

GET : 쿼리 파라미터(쿼리 스트링)로 데이터 전달

Content-Type : application/json을 주로 사용(사실상 표준) - TEXT, XML JSON 등이 있음

---

2. HTTP API 설계 예시

• POST 기반 등록 - 신규 자원 등록 특징

회원 등록 : /members  → POST

 

클라이언트는 등록될 리소스의 URI를 모른다.

서버가 새로 등록된 리소스 URI를 생성

서버가 중심이 되어 리소스 URI를 생성하고 관리하는 것을 컬렉션(Collection)이라고 부름

여기서 컬렉션은 /members

 

• PUT 기반 등록 - 신규 자원 등록 특징

파일 등록 : /files/{filename} → PUT

 

클라이언트가 등록될 리소스의 URI를 알고 있다.

클라이언트가 직접 리소스의 URI를 지정하여 요청한다. 그래야 없으면 새로 만들고, 있으면 덮어쓸 수 있음

클라이언트가 중심이 되어 URI를 알고 관리하는 것을 스토어(Store)라고 부른다

여기서 스토어는 /files

 

• HTML FORM 사용

HTML FORM 태그는 GET, POST만 지원그로 인해 제약이 있고, AJAX 같은 기술을 통해 해결은 가능

 

회원 등록 폼 : /members/new → GET

회원 등록 :     /members/new, /members → POST

 

위처럼 회원 등록 또는 수정을 위해

1. FORM을 보여주기 위한 GET 요청 URI 존재

2. 해당 FORM에 데이터를 입력한 뒤 등록을 위한 POST 요청 URI가 존재

 

여기서 등록을 위한 URI를 선택할 때 두 가지 경우를 선택할 수 있습니다.

권장사항으로는 조회와 등록의 URI를 일치시켜 서버 측 이슈 또는 유효성으로 인한 reload 시 깔끔하게 구현 가능 (선택은 자유)

 

회원 삭제 : /members/{id}/delete → POST

 

DELETE 메서드를 사용하고 싶지만 FORM 태그는 GET과 POST만 지원하기 때문에 사용 불가

이럴 때 사용하는 것이 컨트롤URI

POST 로 요청하고, URI 끝에 어떠한 행위를 할 건지 의미하는 동사를  사용하여 URI 생성

HTTP 메서드로 해결하기 애매한 경우 사용

---

3.  정리 - 참고하면 좋은 URI 설계 개념

• 문서(document)

단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)을 문서라고 칭함

예) /members/100, /files/star.jpg

 

• 컬렉션(collection)

서버가 리소스의 URI를 생성하고 관리

 

• 스토어(store)

클라이언트가 리소스의 URI를 알고 관리

 

• 컨트롤러, 컨트롤 URI

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행

동사를 직접 사용

예) /members/{id}/delete