[HTTP] HTTP 메소드 활용, collection, store, POST 기반 설계, PUT 기반 설계

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

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

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

HTTP를 이용한 데이터 전달 방식은 크게 2가지이다.

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

정적 데이터 조회와 동적 데이터 조회

데이터 조회에는 정적 데이터 조회와 동적 데이터 조회, 두 가지 상황이 있다.

1. 정적 데이터 조회

• 이미지, 정적 텍스트 문서
• 일반적으로 쿼리 파라미터 없이 리소스 경로만으로 조회 가능
• GET 사용

2. 동적 데이터 조회

• GET은 쿼리 파라미터를 사용해서 데이터 전달.
  • www.google.com/search?q=hello&hl=ko
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용한다.

HTML form VS HTTP API

데이터를 전송하는 방식에는 HTML from 태그를 활용하는 방식과 HTTP API를 호출하는 방식, 두 가지가 있다.

1. HTML form을 통한 데이터 전송

HTML form을 이용한 전송은 GET과 POST만 지원한다.

• 회원 가입, 상품 주문, 데이터 변경
• POST 전송
• input 태그의 name속성이 추후 응답 바디의 key가 된다.

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

• 요청 메세지 헤더의 content-type이 content-type: application/x-www-form-urlencoded 라는 값으로 데이터가 전송된다.
• 위 예시에서 메세지 바디는 username=kim&age=20 이다.
• 근데 위 예시를 GET으로 바꾸면 username=kim&age=20 이것이 쿼리파라미터로 변경되어서 날아단다. 하지만 GET은 조회 때만 사용하자.
• multipart/form-data: 파일 같은 거 전송할 때 사용한다.

<form enctype="multipart/form-data"></form>

• 이렇게 해주면 요청 메세지의 content-type이 content-type: multipart/form-data; boundary=----XXX 등으로 변해서 날아감.

정리

• HTML FORM submit POST 전송

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

• content-type: applcation/x-www-form-urlencoded 사용

  • form의 내용을 베세지 바디를 통해서 전송(key-value)
  • 전송 데이터를 url encoding 처리 (예) abc김 --->> abc%EA%B9%80)
  • HTML FORM은 GET 전송도 가능함 (조회 때만 사용. 데이터는 쿼리파라미터로 들어감)

• content-type: multipart/form-data

  • 파일 업로드 같은 바이너리 데이터 전송 시 사용
  • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 멀티파트)

• HTML 전송은 GET과 POST만 지원

• HTML API를 통한 데이터 전송

  • 클라이언트에서 서버로 바로 데이터를 전송해야 할 때
  • 회원 가입, 상품 주문, 데이터 변경

• 서버 to 서버, 앱 클라이언트

• 웹 클라이언트(ajax): HTML FORM 전송 대신 자바스크립트를 통한 AJAX. React나 Vue같은 웹클라이언트 프레임워크와 API 통신

• POST, PUT, PATCH는 메세지 바디를 통해 데이터 전송

• GET 조회, 쿼리 파라미터로 데이터 전달

• content type은 text, xml, json 등이 있지만, content-type: application/json이 사실상 표준

2. HTTP API 설계 예시

HTTP 설계는 크게 POST 기반 설계와 PUT 기반 설계로 나뉘는데, 주로 사용되는 건 POST 기반 설계이다.

http api 컬렉션

• post 기반 등록
• 서버가 리소스 URI 결정(중요)
• 예) 회원관리 api 제공

http api 스토어

• put 기반 등록
• 클라이언트가 리소스 URI 결정(중요)
• 정적 콘텐츠 관리, 원격 파일 관리

html form 사용

• 웹페이지 회원 관리
• get, post만 지원
• 순수한 HTML만 사용할 때(자바스크립트 없이)
• 컨트롤 URI를 사용 해야 함

회원 관리 시스템

POST 기반 등록 설계로 회원 관리 시스템을 만들었다고 가정하자.

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

POST로 신규 자원 등록할 때 중요한 특징은

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

즉 클라이언트가 POST /members를 호출하면

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

응답 메세지 헤더에 location: /members/100 반환한다.

클라이언트는 데이터 처리를 요청할 뿐이다.

정리하면

컬렉션 collection

• 서버가 관리하는 리소스 디렉토리
• 서버가 리소스의 URI를 생성하고 관리
• 여기서 컬렉션은 /members

파일 관리 시스템

이번에는 PUT 기반 등록 설계로 파일 관리 시스템을 만드는 상황을 가정하자.

• 파일 목록 GET /files
• 파일 조회 GET /files/{filename}
• 파일 등록 PUT /files/{filename}
• 파일 삭제 DELETE /files/{filename}
• 파일 대량 등록 등 다른 행위 POST /files/blahblah

가장 중요한 차이점은 위에서 말했듯 클라이언트가 파일의 이름을 알고 있다는 것이다.

디렉토리 내에 파일을 집어넣는다고 생각해보자. 이름이 똑같은 게 이미 있다면 기존 파일 대체한다.

PUT 신규 자원 등록 특징은

클라이언트가 리소스 URI를 알고 있어야 한다.

• 파일 등록 PUT /files/{filename}
• PUT /files/stat.png

즉, 클라이언트가 직접 리소스의 URI를 지정한다.

정리하면

스토어 store

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

하지만 실무에서는 대부분 POST 기반으로 사용한다.

HTML FORM 사용

• html form 은 get, post만 지원

• 다른 메소드를 사용하려면 ajax 같은 기술을 사용해야 한다. -> 회원 API 참고

• 여기서는 순수 HTML FORM만 사용한다고 가정한다.

• get, post만 지원하므로 제약이 있음

• 회원 목록 GET /members

• 회원 등록 폼 GET /members/new

• 회원 등록 POST /members/new || /members

• 회원 조회 GET /members/{id}

• 회원 수정 폼 GET /members/{id}/edit

• 회원 수정 POST /members/{id}/edit || /members/{id}

• 회원 삭제 POST /members/{id}/delete

HTML FORM 은 GET, POST만 지원

컨트롤 URI 사용해야함(URI에 동사 등을 집어넣어 행위을 유추하게 함)

컨트롤 URI

• HTTP 메소드로 해결하기 애매한 경우 사용함.
• 컨트롤 URI는 남발하지 말고 정말 제한적으로 사용해야함
• 예시) /new /edit /delete

참고하면 좋은 URI 설계 개념

restfulapi.net/resource-naming

1. 문서 document

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

2. 컬렉션 collection

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

3. 스토어 store

• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 uri를 알고 간리
• /files

4. 컨트롤러, 컨트롤 uri // controller, control URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동서를 직접 사용
• /delivery/start

결론: CRUD는 최대한 리소스는 URI로, 행위는 메소드로 나타내고, 그 이외의 작업은 컨트롤 URI와 POST를 이용하자