11장 API를 위한 HTTP

  • WWW가 기술스택이라면 3단계로 나눌 수 있다.
    • 맨 아래: URL, 리소스
    • 리소스 위: HTTP 프로토콜, 리소스 표현을 읽는 권한한과 기본적인 리소스 상태에 쓰는 권한
    • 맨 위: 하이퍼미디어, 하나의 웹 사이트나 API의 프로토콜 의미 체계 ⇒ 이 책에서 지금까지 다룬 것

새로운 HTTP1.1 설계 명세서

  • RFC 2616
  • HTTP 프로토콜 의미 체계를 명확히 하는 것

응답 코드

  • 엔티티 바디는 응답 코드에 대한 설명(문제가 무엇인지)이 담겨야 한다.
  • 200(OK)와 에러 메시지를 함께 보내지 마라.
  • RFC 2616에 있는 것 외에 새로운 것을 정의히지 마라

헤더

  • RFC 2616에 있는 것 외에 새로운 것을 정의하지 마라

표현들 사이에서 선택하기

  • 서버가 하나의 리소스에 대해 다양한 표현을 제공할 때 클라이언트가 이것들을 어떻게 구분해야 할까?

  • 클라이언트가 어떤 표현을 원하는지에 대해 어떻게 신호를 보내야 할까?

    콘텐트 협상

    • 어떠한 표현을 원하는지 서버에 알리기 위해 사용하는 HTTP 요청 헤더
    • Accept나 Accept-Language에 담아 보낸다.

    하이퍼미디어 메뉴

    • 일반적으로는, GET 요청으로 받은 것에서 클라이언트가 따라가길 원하는 연결을 선택하고 다른 표현을 갖기 위해 다른 GET 요청을 만든다.

정규 URL(Canocical URL)

  • 리소스가 여러 URL을 가지면 하나를 공식적인 정규 URL로 결정해야 한다.
  • 표준 HTTP 헤더 Content-Location이 가리키거나
  • IANA에 등록된 연결 관계인 canonical을 사용하여 가리킨다.

HTTP 성능

캐싱

  • 의미 없는 요청들을 감소 시키는 것
  • HTTP 헤더의 Cache-Control을 사용하여 웹 API에 캐시를 추가할 수 있다.
  • ex) max-age: 재 요청까지 기다려야 하는 시간
  • ex2) no-cache: 응답을 캐시하지 말것

조건적 GET(Conditional GET)

  • 의미 없는 요청에 대한 비용을 서버가 감소시키기 위해
  • 리소스 상태의 변경이 없으면 서버의 요청을 제거하는 것
  • 응답의 Last-Modified 헤더는 언제 변경되었는 지를 말해준다.
  • 다음 요청의 If-Modified-Since 헤더에 이 값을 담아 보낸다.
    • 표현이 변경되었으면 새로운 Last-Modified와 새로운 표현이 온다.
    • 표현에 변경이 없으면 304가 바디 없이 온다.
    • 근데 변경 사항을 계속 추적하고 저장해야함..
    • 컬렉션 리소스는 내부의 포함되는 모든것의 시간과 연관되게 된다.
  • ETag: 표현이 변경되야 할떄마다 변경되어야 하는 값
    • 응답에서 받은것을 두번째 요청떄 If-None-Match로 보내준다.
  • timestamp와 ETag가 뭔차이가있는건지 모르겠다.
  • 결국마지막에 변경된 시점에 무언가 값을 가지고있는건 매한가지아닌가?

LBYL(Look-Before-You-Leap) 요청

  • 누울자리 보고 누워라..?
  • Expect: 100-continue : 나 이요청 보내도 되냐?
    • 100(Continue) - ㅇㅋ
    • 417(Exception Failed) - ㄴㄴ

압축

Accept-Encoding 헤더: 어느 압축 알고리즘을 클라이언트가 이해할 수 있는가

부분 GET(Partial GET)

  • 클라언트가 표현의 일부분만 받을 수 있도록 허용
  • 중단된 다운로드 재개

파이프라이닝

  • 클라이언트가 여러개의 HTTP 요청을 한 번에 보낼 수 있도록 허용함으로써 지연을 감소시킴
  • 쓰지말자. 멱등성 문제도 있고, 같은 도메인에 길고 연속된 요청들을 보낼때만 성과를 낸다.

업데이트를 못한 문제 피하기

이러한 조건적 GET은 클라이언트가 표현의 상태가 변했는지를 알 수있게 해준다.

근데 클라이언트가 언제 요청을 보낼지를 구현하는게 가장 빡센거아닌가?

인증

  • 인증의 두 단계
    • 사용자가 자신의 증명을 서버에 제공하는 것
    • 이 사용자의 증명을 각 API를 요청할 때마다 자동으로 첨부하는 것

WWW-Authenticate과 Authorization 헤더

기본 인증

안전하지 않다. 다 노출되니까. 클라이언트에게 모두 같은 증명을 줘야한다.

OAuth 1.0

제 3의 API 제공자가 서버에 증명을 제공한다.

하지만 별도의 브라우저 팝업이 떠야한다.

OAuth 2.0

  1. 승인코드 제공(위 OAuth 1.0 방식)
  2. 암묵적 승인(액세스 토큰이 포함된 URL로 리다이렉트)
    1. 페북,구글 로그인등이 이런거구만
  3. 리소스 소유자 비밀번호 증명서
    1. API 제공자에서 사용하는 계정정보(ID, Password) 제공
    2. 콘솔, 모바일 기기에선 어쩔수 없다…
  4. 클라이언트 증명서
    1. 내가가 클라이언트를 API 제공자에 등록할 때, 이 API 제공자에 있는 계정에 자유롭게 접근할 수 있는 권한을 클라이언트에 주는 증명서를 자동으로 받는다.

HTTP 확장

새로운 메서드들과 HTTP

PATCH 메서드

  • 안전하지도 않고 멱등성도 없다.
  • PUT의 성능 문제 해결
  • 멱등성은 있지만 안전하지 않다.
  • 두 리소스 사이에 연결을 생성

WebDAV

  • 파일시스템 작업
  • 원격 파일시스템에 파일과 디렉터리를 위한 HTTP 리소스들을 편하게 게시하는 것
  • MOVE, COPY 처럼 파일시스템같은 메서드들이 정의되어있음.

HTTP 2.0

  • 프로토콜 의미 체계를 유지하면서 HTTP 성능을 향상시키기 위한 목표