#5 HTTP_메서드 활용

HTTP_메서드 활용

 

1. 데이터 전송

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

 

· 쿼리 파라미터를 통한 데이터 전송

  - GET

  - 주로 정렬 필터(검색어)

 

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

  - POST, PUT, PATCH

  - 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 등

 

또한 클라이언트에서 서버로 데이터를 전송하는것은 크게 4가지 상황으로 구분할 수 있다.

 

■ 정적 데이터 조회

· 이미지, 정적 텍스트 문서 등

· 조회는 GET을 사용

· 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능하다.

 

 

[정적 데이터 조회]

 

■ 동적 데이터 조회

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

· 조회는 GET을 사용

· GET은 쿼리 파라미터를 사용해서 데이터를 전달

 

 

[동적 데이터 조회]

 

■ HTML Form을 통한 데이터 전송

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

· Content-Type: application/x-www-form-urlencoded를 사용

· form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)

 - 전송 데이터를 url encoding 처리

 ex) abc김 -> abc%EA%B9%80

· HTML Form은 GET 전송도 가능하다.

· Content-Type: multipart/form-data

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

 - 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

· HTML From 전송은 GET, POST만 지원

 

 

[POST 전송]

HTML을 통해서 username과 age의 값을 지정하고 HTTP 메세지를 생성한다.

 

이 때 HTML From을 통해 생성된 HTTP 요청 메시지의 헤더에는 Content-Type: application/x-www-form-urlencoded 가 사용 된다.

 

데이터는 쿼리 파라미터 형식으로 전달된다.

 

 

[multipart/form-data]

파일과 같은 바이너리 데이터를 포함해 복수의 데이터를 전송할 때는 HTML에 multipart/form-data 형식을 추가해서 사용한다.

 

생성된 HTTP에는 Content-Type: multipart/form-data 가 사용되며 각 데이터는 형식에 따라 구분되서 메시지 바디에 작성된다.

 

 

■ HTTP API를 통한 데이터 전송

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

· 서버 to 서버, 앱 클라이언트, 웹 클라이언트 

· GET, POST, PUT, PATCH 등을 이용

· Content-Type: application/json을 주로 사용(사실상 표준)

 

 

[HTTP API 데이터 전송]

JSON 형식의 데이터를 전송하며, 헤더에 Content-Type: application/json 가 사용된다.

 

 

2. HTTP API 설계

 

API URI를 설계할 때 가장 중요한것은 리소스 식별이다.

 

예를들어 회원에 관한 API를 설계한다고 하자.

 

˙ 회원 목록 조회 / read-member-list

˙ 회원 조회 / read-member-by-id

˙ 회원 등록 / create-member

˙ 회원 수정 / update-member

˙ 회원 삭제 / delete-member

 

위와 같이 회원이라는 리소스에 접근해서 행할 행위의 이름으로 URI를 설계할 수 있다.

 

얼핏 보면 각 행위에 대해 URI가 명확해보여서 잘 설계되었다고 생각된다.

 

그러나 URI는 리소스행해지는 행위보다 리소스를 식별하는것에 중점을 두어야된다.

 

즉, 회원에 대한 API를 설계할때 다음과 같은 방식이 바람직하다고 볼 수 있다.

 

˙ 회원 목록 조회 / members
˙ 회원 조회 / members/{id}
˙ 회원 등록 / members/{id}
˙ 회원 수정 / members/{id}
˙ 회원 삭제 / members/{id}

 

위와 같이 회원이라는 자원을 식별하게만하고 행위에 대한 구분은 HTTP 메서드를 통해서 하는것이 바람직하다.

 

■ POST 기반 등록

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

˙ 서버가 새로 등록된 리소스 URI를 생성해준다.

˙ 위와 같은 이유로 회원 관리 API에 사용된다.

 □ 컬렉션

 ˙ 서버가 관리하는 리소스 디렉토리

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

 

 

[회원 관리 API_POST 방식]

위 예제에서 컬렉션은 members이다.

 

■ PUT 기반 등록

˙ 클라이어가 등록한 리소스 URI를 알고 있어야 한다.

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

˙ 위와 같은 정적 컨텐츠 관리, 원격 파일 관리에 사용된다.

 □ 스토어

 ˙ 클라이언트가 관리하는 리소스 저장소

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

 

 

[파일 관리 API_PUT 방식]

위의 예제에서 스토어는 /files이다.

 

■ HTML FORM 사용

˙ 순수 HTML+HTML From 사용

˙ GET, POST만 지원한다.

 □ 컨트롤 URI

 ˙ GET, POST만 지원하므로 어쩔수 없이 동사로 된 리소스 경로를 사용해야 할 경우도있다.

 

 

[회원 관리 API_HTML FORM 방식]

일부 API는 컨트롤 URI를 사용했다.