김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의 내용을 정리한 노트입니다. 블로그에 있는 자료를 사용하실 때에는 꼭 김영한님 강의 링크를 남겨주세요!

1. API URI

• API URI 설계 시 가장 중요한 것은 리소스의 식별
• 리소스의 의미를 담아야 함
• 회원을 조회하고, 등록하고, 수정하는 것은 리소스가 아님!
• 회원이라는 개념 자체가 리소스 → 회원이라는 리소스를 URI에 맵핑
• 리소스 자체를 식별하는게 URI의 핵심 → 리소스와 해당 리소스를 대상으로 하는 행위를 분리 → URI는 리소스만 판별하고, 행위는 판별하면 안됨.
• 그런데.... 모두 리소스 기준이면 uri를 어떻게 구분하지???
• 그걸 해주기 위해 필요한 게 HTTP 메소드!

2. HTTP 메소드

2-1. GET

• 이름 그대로 리소스를 조회 → URI에 있는 자원을 주세요
• 전달하려는 데이터는 query를 통해 전달 → 최근 스펙에는 메시지 바디에 넣어서 받을 수 있음 → 그러나 지원을 하는 곳이 많지 않기 때문에 권장하지는 않음

2-2. POST

• 요청 데이터를 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 요청 데이터를 어떻게 처리???
  • 의미가 굉장히 많음....
  • 이 리소스 uri에 요청이 오면 데이터를 어떻게 처리할지 리소스마다 따로 정해야함 → 즉, 정해진 것이 없음
• 정리하자면...
  • 새 리소스를 생성하고 등록
  • 프로세스를 처리(프로세스의 상태가 변하는 경우) → 이 경우, post 결과 새로운 리소스가 생성되지 않을 수 있음
    • 컨트롤 URI가 사용될 수 있는데 행위가 uri에 들어가는 경우가 있음 → 실무에서 리소스만 가지고 uri를 만들기 힘듬 ex) orders/{orderId}/start_delivery → start_delivery가 컨트롤 uri
  • 다른 메소드로 처리하기 어려운 경우 → 어떤 http 메소드를 선택할지 애매하다면 post!

2-3. PUT

• 리소스를 대체 → 완전히 대체(덮어쓰기)

• 클라이언트가 리소스의 전체 위치를 알고 URI 지정 → 아래의 이미지 처럼 members/100 의 리소스 위치를 다 알고 있음

  

  • 반대로 post는 리소스의 위치를 전혀 알지 못함

• put은 쉽게 생각해서 기존의 리소스를 지우고 새롭게 리소스를 만든다고 생각하면 편함 → put은 수정용이 아님!(리소스가 덮어쓰여지기 때문)

• 리소스 완전 대체의 개념 예시

  

  

2-4. PATCH

• 리소스를 부분만 변경
• 위의 put의 완전 대체 예시처럼 보내질 경우(username 없이) → age의 값만 변경됨

2-5. DELETE

• 리소스 제거

3. HTTP 메소드 속성

3-1. 안전

• 호출해도 리소스가 변경되지 않음
• 여기에 해당하는 HTTP 메소드는 get
• 안전에 대한 속성은 리소스의 변화에 대해서만 체크하지 외부 요인은 고려하지 않음(잦은 호출로 서버가 터진다면..??? 등등)

3-2. 멱등

• 한 번 호출하든 100번 호출하든 결과는 똑같음
• 똑같은 요청을 여러번 해도 같은 결과가 나옴 → 서버가 비정상 응답을 했을 시 같은 요청을 또 해도 되는가에 대한 근거로 활용 + 자동복구 메커니즘
• 멱등은 외부요인으로 중간에 리소스가 변경되어 다른 결과가 나오는 것까지 고려하지 않음

3-3. 캐시가능

• 응답 결과 리소스를 캐시해서 사용 가능한가
• 주로 실무에서는 get 정도만 캐시로 사용

블로그에 있는 자료를 사용하실 때에는 꼭 김영한님 강의 링크를 남겨주세요!
(강의 링크 : https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)