CS

HTTP 메서드 활용

토니짱 2022. 9. 25. 22:29

쿼리 파라미터 전달

  • GET
  • 주로 검색어나 정렬 조건을 넣을 때 사용함.

메시지 바디에 전달

  • POST, PUT, PATCH
  • 회원 가입, 주문, 리소스 등록, 변경에 사용함.

 

클라이언트에서 서버로 데이터 전송하는 4가지 상황

1. 정적 데이터 조회

  • 이미지, 정적 텍스트 문서 전달
  • GET 사용
  • 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

쿼리 파라미터로 추가적인 데이터 전달 없이 경로만 넣으면 그냥 이미지 리소스를 만들어 보내줌.

 

2. 동적 데이터 조회

  • 주로 검색, 게시판 목록 정렬 필터 등에 사용됨
  • GET사용 : 쿼리 파라미터를 사용해 데이터 전달

경로에 검색어나 추가 조건을 쿼리 파라미터에 넣어 보낸다. 서버는 key:value로 꺼내어 결과를 만들어 보내준다.

 

3. HTML Form 데이터 전송

HTML Form 전송은 GET, POST만 지원한다.

POST

form submit 버튼을 누르면 form 데이터를 읽어서 http메시지를 생성해준다.

  • Content-Type:application/x-www-form-urlencoded (Content-Type의 기본값이다)
  • username=kim&age=20
  • 전송 데이터를 url encoding 처리한다.

위 정보를 http body에 담아 보낸다.

 

GET

만약 GET으로 바꾸어 폼 데이터를 전송하면 웹 브라우저는 http메시지를 GET처럼 쿼리 파라미터로 만든다.

  • Content-Type : multipart/form-data
  • 파일 업로드 같은 바이너리 데이터 전송 시 사용
  • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

하지만 GET은 조회에만 사용해야 한다! 절대로!!!

 

4. 파일 전송

  • Content-Type : multipart/form-data
    byte로 되어있는 바이너리 파일을 같이 보낼 수 있다. 그럼 boundary라는 애가 자동으로 경계를 잘라준다.

 

HTTP API 데이터 전송

  • 서버끼리 통신할 때 html 없이 데이터만 전송한다.
  • 앱 클라이언트에서 데이터를 전송할 때
  • 웹 클라이언트와 통신할 때
    - html의 form 전송 대신, 자바 스크립트를 통해 전송 = AJAX통신
    - react, vue 같은 웹 클라이언트와 API 통신

특징

  • POST, PUT, PATCH 사용 시
    메시지 바디로 데이터 전송
  • GET 사용 시
    조회용
    쿼리 파라미터로 데이터 전송
  • Content-Type:application/json을 주로 사용한다.
    사실상 표준
    TEXT, XML, JSON 등이 있는데 이젠 대부분 JSON 사용

 

HTTP API 컬렉션

API는 리소스만 관리해야 한다. 어떤 일을 할지는 HTTP 메서드로 푼다.

  • 수정에서 PUT은 완전히 덮어쓰는 기능이므로 부분 업데이트를 하는 PATCH를 쓰는 것이 좋다.
  • 게시글을 수정하는 경우라면 완전히 덮어쓸 수 있으므로 PUT을 사용할 수 있다. 
  • 애매하면 POST를 사용한다.

 

POST로 신규 자원 등록

  • 클라이언트는 등록될 리소스의 URI를 모른다.
  • 서버가 새로 등록된 리소스 URI를 생성해준다.
    Location : /members/100
    100이라는 식별자가 서버에서 만들어진다.
  • 컬렉션
    - 서버가 관리하는 리소스 디렉터리
    - 서버가 리소스의 URI를 생성하고 관리함
    - 여기서 컬렉션은 /members를 의미한다.

 

HTTP API 스토어

PUT으로 신규 자원 등록

파일을 새로 업로드할 때는 PUT이 적합하다. 기존 파일이 있으면 지우고 다시 올려야 하기 때문이다.

PUT을 자원 등록 용도로 사용하고 있기 때문에 POST를 임의로 정할 수 있다. 여기서는 파일 대량 등록을 POST로 지정했다.

  • 클라이언트가 리소스 URI를 알고 있어야 한다.
    - file/{filename} -> filename이라는 식별자를 알고 있어야 한다.
  • 클라이언트가 직접 리소스의 URI를 지정하고 관리한다.
    - POST로 생성할 때는 데이터만 넘기면 서버가 알아서 만들어 내려준다.
  • 스토어
    - 클라이언트가 관리하는 리소스 저장소
    - 클라이언트가 리소스의 URI를 알고 관리
    - 여기서 스토어는 /files를 의미한다.

대부분 POST로 생성한다. 파일과 같은 특수한 경우에만 PUT사용.

 

HTML FORM 사용

순수한 HTML FORM만 사용한다면 GET, POST만 사용 가능

폼에 데이터를 입력하고 submit 해서 등록할 때는 두 가지를 선택할 수 있다.

  • /members/new
    - 폼을 불러올 때와 실제 데이터를 등록할 때 같은 URI를 써서 메서드만 다르게 요청하는 방법
  • /members
    - 폼을 불러올 때만 /new를 쓰고 실제 등록할 때는 /members를 사용하는 방법
  • 같은 URI를 사용하면서 메서드만 다르게 하는 것을 선호한다.
    - 데이터에 문제가 있어서 서버에 보낸 값을 다시 폼에 던져야 할 때가 있다. 이때 URI가 통일되어 있으면 경로를 수정하지 않고도 깔끔하게 해결할 수 있다.
    - 통일하지 않으면 리프레시를 하거나 경로를 벗어나면 다시 그 경로로 돌아갈 수 없다.

수정 폼도 실제 수정하는 게 아니라 폼을 불러오기만 할 뿐이므로 GET을 사용한다. 이때도 두 가지 방법이 있다.

1. /members/{id}/edit

2. /members/{id}

등록과 같은 이유로 통일하는 방법을 추천한다.

 

컨트롤 URI

HTML FORM은 delete를 쓰지 못하므로 삭제할 때는 어쩔 수 없이 /delete/delete를 붙여서 컨트롤 URI라는 형태로 사용해야 한다.

  • GET, POST만 지원하므로 제약이 있다.
  • 이런 제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.
  • POST의 /new , /edit , /delete 가 컨트롤 URI가 된다.
  • HTTP 메서드로 해결하기 애매한 경우 사용한다.
    - HTTP API에서도 적용된다.
    - 하지만 정말 안될 때만 사용한다.

 

URI 설계 개념

문서(document)

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

컬렉션(collection)

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

스토어(store)

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

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

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

 

반응형