HTTP - HTTP 메서드 활용

들어가며

• 이전 포스트에서 HTTP 메서드의 각 특징과 성질에 대하여 알아보았다.
• 이번엔 이전에 배운 HTTP 메서드를 활용하여 클라이언트에서 어떻게 서버로 데이터를 전송하는지에 대해 알아본다.

HTTP - HTTP 메서드

 

 

데이터 전송 - Client to Server

• 클라이언트(호스트)에서 서버로 데이터를 전송하는 것은 크게 두 가지로 나눌 수 있다.
  • 하나는 쿼리 파라미터를 사용한 데이터 전송이다.
    • 쿼리 파라미터는 localhost:8080/members?id=100 에서 ? 이후에 들어오는 key=value를 말한다.
    • GET 메서드가 해당 방식을 사용하며 GET 전송의 경우 일반적으로 어떤 컬렉션(데이터의 집합)을 조회하는 방식으로 만약 조회된 데이터가 매우 많을 경우에 이를 필터링하거나 정렬하는데에도 사용된다.
  • 다른 하나는 HTTP 메시지의 바디를 사용한 데이터 전송이다.
    • POST, PUT, PATCH 메서드에서 사용되는 방식으로 HTTP 메시지에 서버에 전송할 여러 데이터를 담아 전송한다.
    • POST의 경우를 보면 알겠지만 리소스 등록이나 변경, 처리에 자주 사용되는 방식이다.
• 또한 클라이언트에서 서버로 데이터를 전송할 때, 데이터의 종류에 따라서도 나뉠 수 있다.
• 첫 번째로는 정적 데이터(static data) 조회이다.
  • 보통 이미지, 정적 HTML 문서들을 보낼때가 이 종류이다.
  • 정적 데이터 조회는 일반적으로 쿼리 파라미터 없이 리소스 경로를 사용하여 단순하게 조회 가능하다.
• 두 번째로는 동적 데이터 조회이다.
  • 이는 주로 검색, 정렬 필터 등의 검색어를 전송할 때 사용되며 쿼리 스트링을 보내는 것이 이러한 분류에 속할 수 있다.

• 세 번째는 HTML의 <Form>을 사용한 데이터 전송이다.
  • 보통 회원가입, 로그인, 상품 주문, 데이터 변경 처리에 사용되는 경우이며 말 그대로 <Form>태그를 사용하여 submit 버튼을 눌렀을 때 서버로 보내지는 데이터 종류이다.
  • 아래의 사진은 POST 요청을 Form 방식으로 전송했을 때 HTTP 메시지인데 Content-Type이 다음과 같이 특수하게 되어 있다.
  • 그리고 메시지 바디를 보면 쿼리 파라미터 형식으로 되어 있으며 여기서 데이터를 꺼낼 수 있다.
  • HTML Form은 GET, POST 방식만 지원하는 것을 유의하자.

• 마지막으로 HTTP API를 사용한 데이터 전송이다.
  • 이는 메시지 바디에 JSON 등을 사용하여 서버에 데이터를 보내는 형식으로 백엔드 시스템간 통신하거나, 앱 클라이언트, AJAX를 위시한 웹 클라이언트에서 사용된다.
  • GET의 경우 쿼리 파라미터나 조회를 통해 데이터를 전달하며 POST, PATCH, PUT의 경우 메시지 바디를 사용하여 데이터를 전송한다.
  • Content-Type의 경우 사실상 JSON이 표준으로 사용되며 TEXT, XML이 사용될 수 있다.

 

 

 

HTTP 메서드를 이용한 API 설계

• 우리가여러 시스템에 대한 API를 구현해야 한다고 가정하자. 여러가지 정책과 구조가 만들어 지고 나면, 생각해야 할 것은 URI를 설계하는 것이다.
• 우리는 이전과는 달리 HTTP 메서드를 알고 있고, 어떻게 URI를 설계해야 하는지에 대해서도 알아보았다. 이제 각 시스템들을 보면서 API를 설계해보고 각 설계의 특징도 살펴보자.

 회원 관리 시스템

• 만들어야 할 것은 결국 회원(Member) 관리 시스템이기 때문에 이 시스템에서 가장 돋보이는 리소스는 곧 회원이 될 것이고, 이는 모든 URI에서 회원(Member)가 식별되어야 한다는 것을 의미한다.
• 동작과 리소스를 때어놓고 설계하면 다음과 같이 나타낼 수 있을 것이다.
  • 회원 목록 조회 - /members -> GET
  • 회원 등록 - /members -> POST
  • 회원 조회 - /members/{id} -> GET
  • 회원 수정 - /members/{id} -> POST, PATCH, PUT
  • 회원 삭제 - /members/{id} -> DELETE
• 해당 API에서 새로운 리소스의 등록은 POST를 통해 수행되고 있다.
• POST의 경우에는 리소스를 새로 등록하고 이때 새로 등록된 리소스의 URI를 반환해줄 수 있다.
• 이때 members를 "컬렉션(Collection)"이라고 할 수 있다.
  • 컬렉션은 서버가 관리하는 리소스 디렉토리로 정의하며 서버가 리소스의 URI를 생성하고 관리한다.
  • 위의 API 시스템에서 컬렉션은 /members가 된다.

파일 관리 시스템

• 위와 마찬가지로 파일과 관련된 시스템이기 때문에 식별되어야 할 메인 리소스는 곧 파일이 될 것이다.
• 동작과 리소스를 때놓고 생각하면 다음과 같이 설계할 수 있다.
  • 파일 목록 조회 - /files - GET
  • 파일 조회 - /files/{filename} - GET
  • 파일 등록 - /files/{filename} - PUT
  • 파일 삭제 - /files/{filename} - DELETE
  • 파일 대량 등록 - /files -> POST
• 여기 URI는 등록에서 위의 회원 관리 시스템과 차이가 나는데 바로 등록에 PUT 메서드를 사용한다는 것이다.
• 이는 우리가 파일을 등록할 때 그 파일의 이름이 지정되어 있기 때문에 이름을 명시에서 넣어주어야 한다, 이전 회원 관리 시스템에서는 회원이 회원들 중 어디에 있어야 하는지는 알 필요가 없기 때문에 지정하지 않아도 되었지만 지금은 파일의 이름이 명시되어야 한다.
• 또한 만약 명시된 이름의 파일이 이미 존재하는 경우에, 해당 파일을 현재 파일로 덮어씌우도록 하기 위해서도 있다.
• 이러한 방식의 특징은 클라이언트가 직접 서버에 해당 리소스의 URI를 지정한다는 것이다.
• 이때 files를 스토어(Store)라고 한다.
  • 스토어는 클라이언트가 관리하는 리소스 저장소를 의미한다. 클라이언트가 리소스 URI를 직접 관리하며 인지하고 있다.
  • 위의 API 시스템에서 스토어는 /files가 될 것이다.

회원 관리 시스템 - with HTML Form

• 만들어야 할 것은 결국 회원(Member) 관리 시스템이기 때문에 이 시스템에서 가장 돋보이는 리소스는 곧 회원이 될 것이고, 이는 모든 URI에서 회원(Member)가 식별되어야 한다는 것을 의미한다.
• 동작과 리소스를 때어놓고 설계하면 다음과 같이 나타낼 수 있을 것이다.
  • 회원 목록 조회 - /members -> GET
  • 회원 등록 form - /members/new -> POST
  • 회원 등록 - /members/new -> POST
  • 회원 조회 - /members/{id} -> GET
  • 회원 수정 - /members/{id}/edit -> GET
  • 회원 수정 form - /members/{id}/edit -> POST
  • 회원 삭제 - /members/{id}/delete -> POST
• 해당 시스템의 특징은 HTML Form을 사용한다는 것으로 HTML Form은 위에서 설명한 것 처럼 GET, POST만 지원하기 때문에 모든 동작을 POST와 GET으로 처리한다
• 두 가지 메서드로만 모든 동작을 구분해야 하기 때문에 제약이 존재하는데 이를 해결하기 위해 컨트롤 URI를 사용한다.
  • 컨트롤 URI는 동사로 된 리소스 경로를 말하는 것으로 POST의 /new, /edit, /delete가 컨트롤 URI라고 할 수 있다.
  • 이러한 컨트롤 URI는 HTTP 메서드로 해결하기 애매한 동작들을 URI로 매핑해야 할 때 사용한다.