HTTP 메서드

API URL

1. 설계

• 가장 중요한 것은 리소스 식별
• 리소스의 의미
  • '회원'이라는 개념 자체가 리소스
  • 회원이라는 리소스만 식별하면 된다.
  • 회원 리소스를 URI에 맵핑
• 리소스와 행위를 분리
  • 리소스는 명사, 행위는 동사
  • 메서드로 구분한다

2. GET, POST

• GET
  • 리소스 조회, 서버에 전달하고 싶은 데이터를 쿼리를 통해 전달
  • 바디를 사용할 수 있지만 권장하지 않음
• POST
  • 요청 데이터 처리
  • 메시지 바디를 통해 서버로 요청 데이터 전달
• POST는 요청 데이터를 어떻게 처리할까?
  • 데이터 블록 처리 프로세스 제공
  • 게시판 글쓰기 등
  • 서버가 아직 식별하지 않은 새 리소스 생성
  • 핵심은 POST 요청이 오면 요청마다 어떻게 처리할지 정하는 것!
  • 단순히 데이터 생성, 변경이 아니라 프로세스를 처리하는 것이다

3. PUT, PATCH, DELETE

• PUT
  • 리소스를 대체
  • 리소스가 없으면 완전히 대체, 있으면 생성
  • 클라이언트가 리소스를 식별(클라가 리소스 위치를 알고 있음)
  • 요청, 응답의 스펙이 다를 경우 리소스를 덮어버림 (PUT은 리소스 수정이 아님)
• PATCH
  • 리소스 부분 변경

4. HTTP 메서드 속성

• 안전
• 멱등
  • 한 번이든 백 번이든 결과가 똑같다.
  • POST는 멱등이 아님
  • 재요청 중 다른 곳에서 리소스 바뀐 건 고려하지 않음
• 캐시가능
  • 응답 결과를 캐시 사용가능 -> GET만

5. HTTP 메서드 활용

• 정적 데이터 조회
• 동적 데이터 조회
  • 쿼리 파라미터로 조회
• HTML Form 전송
  • 웹 브라우저가 Form을 읽어서 HTTP 메시지를 생성해줌.
• 멀티파트 전송
  • 파일 업로드는 바이너리 데이터
• HTTP API 전송
  • 서버 to 서버
  • 웹 클라이언트에서 ajax로 통신

5. HTTP API 설계 예시

6. HTTP 상태 코드

• 2XX
  • 201 : created, 요청 성공 후 새로운 리소스 성공
  • 202 : 요청 접수 되어있지만 수행 안됨
  • 204 : 요청 성공. 근데 응답값은 없음
• 3xx
  • 리다이렉션: 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동
  • 일시적 리다이렉션 : POST로 주문 후 웹 브라우저 새로고침, 새로고침은 다시 요청 -> 중복요청임
• 4xx
  • 401: 인증이 되지 않음. 인증(로그인), 인가(권한부여)

헤더

1. HTTP 헤더

• 표현
  • Content-Type: 미디어 타입, 문자 인코딩 등
  • Content-Encoding: 표현데이터 압축, 데이터 읽는 쪽에서 해제
  • Content-Language: 표현데이터의 자연 언어 표현
• 협상
  • Accept: 클라이언트가 선호하는 미디어타입

2. HTTP 전송방식

• 단순 전송
  • Content-Length를 알면 주면 됨
• 압축 전송
  • 서버에서 압축함
• 분할 전송
  • Content-Length 보내면 안됨
• 범위 전송

3. HTTP 정보

• From : 유저 에이전트 이메일 정보, 검색 엔진에서 사용
• Referer : 이전 웹페이지 주소
• Host : 요청한 호스트 정보
• Location: 리다이렉트하는 주소

4. HTTP 인증

• Authorization: Basic XXXX...

5. HTTP 쿠키

• Set-Cookie: 서버에서 클라로 쿠키 전달
• Cookie: 클라가 서버에서 받은 쿠키 저장
• 쿠키
  • 클라가 로그인하면 서버에서 Set-Cookie사용하여 쿠키 정보 담음
  • 웹 브라우저의 쿠키 저장소에 정보 저장
• 쿠키 생명주기
  • expries: 만료일 되면 쿠키 삭제
  • max-age: 0이나 음수면 쿠키 삭제
  • 세션쿠키와 영속쿠키가 있음
• 쿠키의 도메인
  • 지정한 도메인에서만!
• 쿠키 보안
  • Secure
    • 쿠키는 http, https 구분하지 않고 전송
    • Secure 적용되어 있으면 https만 전송
  • HttpOnly
    • XSS 공격 방지
    • JS에서 접근 불가
    • HTTP 전송만 사용
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인, 쿠키 설정된 도메인이 같은 경우만

캐시

1. HTTP 캐시

• cache-control: 캐시가 유효한 시간
• 유효 시간이 지나면 브라우저는 데이터를 다시 받음. 근데 데이터가 동일해도 또 받아야 할까?

2. 검증 헤더와 조건부 요청

• last-modified : utc 표기형으로
• 만약 max-age가 지났으면 검증 헤더에 If-Modified-Since 요청 헤더를 붙여서 서버에 보냄
• 서버에서 데이터가 수정되었나 검증함
• 최종수정일을 보고 304 not modified 응답(바디가 없음)
• 웹 브라우저에서 304를 받으면 헤더 데이터 갱신

3. ETag

• 조건부 요청 헤더
  • 검증 헤더로 조건에 따른 분기
  • If-Modified-Since: Last-Modified 사용
  • If-None-Match : ETag 사용
  • 조건 만족하면 200, 조건 만족하지 않으면 304
• ETag
  • Entity Tag, 캐시용 데이터 임의의 고유한 버전 이름을 달아둠
  • 데이터 변경되면 이름 바뀌어서 변경함
  • 캐시 제어 로직을 서버에서 완전히 관리

4. 캐시와 조건부 요청 헤더

• Cache-Control
  • no-cache: 데이터는 캐시 되지만, 항상 서버에서 검증
  • no-store: 데이터에 민감한 정보가 있으므로 저장 안함
• Pragma
  • HTTP 1.0 하위 호환
• Expires
  • 캐시 만료일을 정확한 만료일로 지정, max-ages를 더 권장함

5. 프록시 서버

• 프록시 캐시
  • 원 서버를 중개해주는 cdn 서비스처럼 (클라우드프론트) 캐시 서버
• Cache-Control
  • public : 응답에 public 캐시, 프록시 캐시
  • private : 응답이 해당 사용만을 위한 것
  • s-maxage : 프록시 캐시에 적용되는 max-age

** 인프런 강의 '모든 개발자를 위한 HTTP 웹 기본 지식' 학습 중