[CS] HTTP 메서드의 속성 및 활용 설계 예시

모든 개발자를 위한 HTTP 웹 기본 지식 | 김영한 - 인프런

HTTP 메서드

• API URI 설계
• 가장 중요한 것은 리소스 식별이다.
• 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
• 회원이라는 개념 자체가 바로 리소스이다.
• 리소스는 어떻게 식별하는게 좋을까?
• 회원을 등록하고 수정하고 조회하는 것을 모두 배제
• 회원이라는 리소스만 식별하면 된다 → 회원 리소스를 URI에 매핑

리소스를 바탕으로 구현한 api는 어떻게 구분해야 할까?

• URI는 리소스만 식별한다.
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야한다.
• 리소스 : 회원
• 행위 : 조회 등록 삭제 변경
• 리소스는 명사, 행위는 동사
• 행위는 어떻게 구분할까?
• 이 행위는 HTTP 메서드로 구분이 가능하다.

HTTP Method - GET, POST

• 주로 많이 사용하는 메서드
  • GET: 리소스 조회
  • POST: 요청 데이터 처리, 주로 등록에 사용
  • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제
• 기타 메서드
  • HEAD: GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환
  • OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용)
  • CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
  • TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해 전달
• body안에 값넣어 보낼수 있지만 권장하지 않음

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터들 처리
  • 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다,.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
• POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다.
• 새 리소스 생성 및 등록
  • 서버가 아직 식별하지 않은 새 리소스 생성
• 요청 데이터 처리
  • 단순 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야하는 경우
• 다른 메서드로 처리하기 애매한 경우
  • JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
• POST는 대부분 모든것을 할 수 있다.

PUT

• 리소스를 대체
• 리소스가 존재하면 대체하고 없다면 생성한다. 덮어버림
• 클라이언트가 리소스 위치를 알고 URI 지정하고 완전히 대체 시킴
• 구체적인 리소스의 전체 위치를 알고있어야 한다.

PATCH

• PUT과 비슷하지만 부분 변경함
• PUT같은 경우 모든 데이터를 덮어버려서 필드가 삭제될 수 있음
• PATCH는 부분 수정을 지원함
• 혹시나 PATCH를 못받는다면 POST 사용하면 됨

DELETE

• 리소스를 제거할 때 사용

HTTP 메서드의 속성

• 안전(Safe Methods)
  • 호출해도 리소스를 변경하지 않는다. → GET 단순조회 → 안전
  • 변경이 일어나는 다른 메서드 → 안전하지 않음
• 멱등(Idempotent)
  • 한 번 호출하든 두번 호출하든 100번 호출하든 결과가 동일하다,
  • 멱등 메서드 → GET, PUT, DELETE, POST
  • 자동 복구 메커니즘 → DELETE를 호출했는데 응답이 없다? → 클라이언트가 자동으로 DELETE를 사용해도 결과가 같음
  • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.
• 캐시가능(Cacheable)
  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용
    • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

HTTP 메서드 활용

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

• 데이터 전달 방식은 크게 2가지
• 쿼리 파라미터를 통한 데이터 전송 - GET
• 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH

HTTP API 데이터 전송

• 서버 to 서버
• 앱 클라이언트
• 웹 클라이언트 → HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용
• POST,PUT,PATCH: 메시지 바디를 통해 데이터 전송
• GET: 조회, 쿼리 파라미터로 데이터 전달
• Content-Type: application/josn 을 주로 사용 (사실상 표준)

HTML API 설계 예시

EX) 회원 관리 시스템

• 클라이언트는 등록될 리소스의 URI를 모른다.
• 서버가 새로 등록된 리소스 URI를 생성해준다.
• 컬렉션 → 서버가 관리하는 리소스 디렉토리

PUT 기반 등록

• HTTP와 Method만으로는 문제해결이 어렵기 때문에 컨트롤 URI를 사용하여 해결

참고하면 좋은 URI 설계 개념

• 문서 (document)
  • 단일 개념
  • /members/100, /files/star.jpg
• 컬렉션 (collection)
  • 서버가 관리하는 리소스 디렉터리
  • 서버가 리소스의 URI를 생성하고 관리
  • 예 /members
• 스토어
  • 클라이언트가 관리하는 자원 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • /files
• 컨트롤러(controller), 컨트롤 URI
  • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  • 동사를 직접 사용
  • /members/{id}/deletHTTP 메서드
    • API URI 설계
    • 가장 중요한 것은 리소스 식별이다.
    • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
    • 회원이라는 개념 자체가 바로 리소스이다.
    • 리소스는 어떻게 식별하는게 좋을까?
    • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
    • 회원이라는 리소스만 식별하면 된다 → 회원 리소스를 URI에 매핑
    
    • URI는 리소스만 식별한다.
    • 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야한다.
    • 리소스 : 회원
    • 행위 : 조회 등록 삭제 변경
    • 리소스는 명사, 행위는 동사
    • 행위는 어떻게 구분할까?
    • 이 행위는 HTTP 메서드로 구분이 가능하다.
    HTTP Method - GET, POST
    • 주로 많이 사용하는 메서드
      • GET: 리소스 조회
      • POST: 요청 데이터 처리, 주로 등록에 사용
      • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
      • PATCH: 리소스 부분 변경
      • DELETE: 리소스 삭제
    • 기타 메서드
      • HEAD: GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환
      • OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용)
      • CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
      • TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
    GET
    • 리소스 조회
    • 서버에 전달하고 싶은 데이터는 query를 통해 전달
    • body안에 값넣어 보낼수 있지만 권장하지 않음
    POST
    • 요청 데이터 처리
    • 메시지 바디를 통해 서버로 요청 데이터 전달
    • 서버는 요청 데이터들 처리
      • 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다,.
    • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
    • POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다.
    • 새 리소스 생성 및 등록
      • 서버가 아직 식별하지 않은 새 리소스 생성
    • 요청 데이터 처리
      • 단순 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야하는 경우
    • 다른 메서드로 처리하기 애매한 경우
      • JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
    • POST는 대부분 모든것을 할 수 있다.
    PUT
    • 리소스를 대체
    • 리소스가 존재하면 대체하고 없다면 생성한다. 덮어버림
    • 클라이언트가 리소스 위치를 알고 URI 지정하고 완전히 대체 시킴
    • 구체적인 리소스의 전체 위치를 알고있어야 한다.
    PATCH
    • PUT과 비슷하지만 부분 변경함
    • PUT같은 경우 모든 데이터를 덮어버려서 필드가 삭제될 수 있음
    • PATCH는 부분 수정을 지원함
    • 혹시나 PATCH를 못받는다면 POST 사용하면 됨
    DELETE
    • 리소스를 제거할 때 사용
    HTTP 메서드의 속성
    • 안전(Safe Methods)
      • 호출해도 리소스를 변경하지 않는다. → GET 단순조회 → 안전
      • 변경이 일어나는 다른 메서드 → 안전하지 않음
    • 멱등(Idempotent)
      • 한 번 호출하든 두번 호출하든 100번 호출하든 결과가 동일하다,
      • 멱등 메서드 → GET, PUT, DELETE, POST
      • 자동 복구 메커니즘 → DELETE를 호출했는데 응답이 없다? → 클라이언트가 자동으로 DELETE를 사용해도 결과가 같음
      • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.
    • 캐시가능(Cacheable)
      • 응답 결과 리소스를 캐시해서 사용해도 되는가?
      • GET, HEAD, POST, PATCH 캐시 가능
      • 실제로는 GET, HEAD 정도만 캐시로 사용
        • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음
    HTTP 메서드 활용
    • 데이터 전달 방식은 크게 2가지
    • 쿼리 파라미터를 통한 데이터 전송 - GET
    • 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH
    HTTP API 데이터 전송
    • 서버 to 서버
    • 앱 클라이언트
    • 웹 클라이언트 → HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용
    • POST,PUT,PATCH: 메시지 바디를 통해 데이터 전송
    • GET: 조회, 쿼리 파라미터로 데이터 전달
    • Content-Type: application/josn 을 주로 사용 (사실상 표준)
    HTML API 설계 예시
    • 클라이언트는 등록될 리소스의 URI를 모른다.
    • 서버가 새로 등록된 리소스 URI를 생성해준다.
    • 컬렉션 → 서버가 관리하는 리소스 디렉토리
    PUT 기반 등록
    • HTTP와 Method만으로는 문제해결이 어렵기 때문에 컨트롤 URI를 사용하여 해결
    참고하면 좋은 URI 설계 개념
    • 문서 (document)
      • 단일 개념
      • /members/100, /files/star.jpg
    • 컬렉션 (collection)
      • 서버가 관리하는 리소스 디렉터리
      • 서버가 리소스의 URI를 생성하고 관리
      • 예 /members
    • 스토어
      • 클라이언트가 관리하는 자원 저장소
      • 클라이언트가 리소스의 URI를 알고 관리
      • /files
    • 컨트롤러(controller), 컨트롤 URI
      • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
      • 동사를 직접 사용
      • /members/{id}/deletHTTP 메서드
        • API URI 설계
        • 가장 중요한 것은 리소스 식별이다.
        • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
        • 회원이라는 개념 자체가 바로 리소스이다.
        • 리소스는 어떻게 식별하는게 좋을까?
        • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
        • 회원이라는 리소스만 식별하면 된다 → 회원 리소스를 URI에 매핑
        
        • URI는 리소스만 식별한다.
        • 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야한다.
        • 리소스 : 회원
        • 행위 : 조회 등록 삭제 변경
        • 리소스는 명사, 행위는 동사
        • 행위는 어떻게 구분할까?
        • 이 행위는 HTTP 메서드로 구분이 가능하다.
        HTTP Method - GET, POST
        • 주로 많이 사용하는 메서드
          • GET: 리소스 조회
          • POST: 요청 데이터 처리, 주로 등록에 사용
          • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
          • PATCH: 리소스 부분 변경
          • DELETE: 리소스 삭제
        • 기타 메서드
          • HEAD: GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환
          • OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용)
          • CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
          • TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
        GET
        • 리소스 조회
        • 서버에 전달하고 싶은 데이터는 query를 통해 전달
        • body안에 값넣어 보낼수 있지만 권장하지 않음
        POST
        • 요청 데이터 처리
        • 메시지 바디를 통해 서버로 요청 데이터 전달
        • 서버는 요청 데이터들 처리
          • 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다,.
        • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
        • POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다.
        • 새 리소스 생성 및 등록
          • 서버가 아직 식별하지 않은 새 리소스 생성
        • 요청 데이터 처리
          • 단순 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야하는 경우
        • 다른 메서드로 처리하기 애매한 경우
          • JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
        • POST는 대부분 모든것을 할 수 있다.
        PUT
        • 리소스를 대체
        • 리소스가 존재하면 대체하고 없다면 생성한다. 덮어버림
        • 클라이언트가 리소스 위치를 알고 URI 지정하고 완전히 대체 시킴
        • 구체적인 리소스의 전체 위치를 알고있어야 한다.
        PATCH
        • PUT과 비슷하지만 부분 변경함
        • PUT같은 경우 모든 데이터를 덮어버려서 필드가 삭제될 수 있음
        • PATCH는 부분 수정을 지원함
        • 혹시나 PATCH를 못받는다면 POST 사용하면 됨
        DELETE
        • 리소스를 제거할 때 사용
        HTTP 메서드의 속성
        • 안전(Safe Methods)
          • 호출해도 리소스를 변경하지 않는다. → GET 단순조회 → 안전
          • 변경이 일어나는 다른 메서드 → 안전하지 않음
        • 멱등(Idempotent)
          • 한 번 호출하든 두번 호출하든 100번 호출하든 결과가 동일하다,
          • 멱등 메서드 → GET, PUT, DELETE, POST
          • 자동 복구 메커니즘 → DELETE를 호출했는데 응답이 없다? → 클라이언트가 자동으로 DELETE를 사용해도 결과가 같음
          • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.
        • 캐시가능(Cacheable)
          • 응답 결과 리소스를 캐시해서 사용해도 되는가?
          • GET, HEAD, POST, PATCH 캐시 가능
          • 실제로는 GET, HEAD 정도만 캐시로 사용
            • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음
        HTTP 메서드 활용
        • 데이터 전달 방식은 크게 2가지
        • 쿼리 파라미터를 통한 데이터 전송 - GET
        • 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH
        HTTP API 데이터 전송
        • 서버 to 서버
        • 앱 클라이언트
        • 웹 클라이언트 → HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용
        • POST,PUT,PATCH: 메시지 바디를 통해 데이터 전송
        • GET: 조회, 쿼리 파라미터로 데이터 전달
        • Content-Type: application/josn 을 주로 사용 (사실상 표준)
        HTML API 설계 예시
        • 클라이언트는 등록될 리소스의 URI를 모른다.
        • 서버가 새로 등록된 리소스 URI를 생성해준다.
        • 컬렉션 → 서버가 관리하는 리소스 디렉토리
        PUT 기반 등록
        • HTTP와 Method만으로는 문제해결이 어렵기 때문에 컨트롤 URI를 사용하여 해결
        참고하면 좋은 URI 설계 개념
        • 문서 (document)
          • 단일 개념
          • /members/100, /files/star.jpg
        • 컬렉션 (collection)
          • 서버가 관리하는 리소스 디렉터리
          • 서버가 리소스의 URI를 생성하고 관리
          • 예 /members
        • 스토어
          • 클라이언트가 관리하는 자원 저장소
          • 클라이언트가 리소스의 URI를 알고 관리
          • /files
        • 컨트롤러(controller), 컨트롤 URI
          • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
          • 동사를 직접 사용
          • /members/{id}/delet
      • 
      • EX) 회원 관리 시스템
      • 클라이언트에서 서버로 데이터 전송
      • 리소스를 바탕으로 구현한 api는 어떻게 구분해야 할까?
  • 
  • EX) 회원 관리 시스템
  • 클라이언트에서 서버로 데이터 전송
  • 리소스를 바탕으로 구현한 api는 어떻게 구분해야 할까?