study restful resource

3. 리소스와 표현

RESTful API

3장 리소스와 표현

  • REST는 설계 제약 조건 모음이다.

무엇이든 리소스가 될 수 있다

  • 사용자가 어떤 작업을 취하고 싶다면 그것을 리소스로 만들어야 한다.
  • 리소스에는 딱 하나의 제약만 있다.
    • 모든 리소스는 URL을 가져야 한다.
    • 다시말해, 무언가에 URL을 부여하면 그건 리소스가 된다.
  • 리소스의 기본 형태는 비트 스트림이다.
  • 클라이언트는 URL과 리소스의 표현만 볼 뿐이다.

표현은 리소스의 상태를 설명한다

  • 표현 : 클라이언트가 리소스에 GET 요청을 보내면 그 리소스를 유용한 방식으로 나타내는 문서를 제공해야 한다.
    • “기계가” 읽을 수 있는 설명으로 나타낸 것

표현은 양방향으로 전송된다.

  • 클라이언트도 POST 요청에서 리소스의 표현을 보낸다.
  • 새 리소스가 어떻게 보여야 하는지에 대한 클라이언트의 생각이 나타난다.
  • 서버는 그 표현을 추가하거나 변경하거나 일부 무시할 수 있다.
    • 데이터베이스 필드에 항상 created_at 과 updated_at 을 남김
  • 표현의 상태 전송
    • 서버는 리소스의 상태를 나타내는 표현을 보낸다.
    • 클라이언트는 그 리소스가 가졌을면 좋을 상태를 설명하는 표현을 보낸다.

많은 표현이 있는 리소스

  • 하나의 리소스에 여러 표현이 있을 수 있다.
    • 다양한 언어, 파일 형식 등
  • 클라이언트가 원하는 표현을 지정하는 법
    • HTTP 헤더의 값
    • 각 표현마다 별개의 URL 부여

HTTP의 프로토콜 의미 체계

  • 클라이언트가 리소스에 원하는 행동에 대한 규칙이 있다.
  • 미리 정의된 프로토콜을 따라 메시지를 보낸다.
  • 웹 API에선 이 프로토콜이 HTTP다.
    • GET: 리소스의 표현을 얻음
    • DELETE: 리소스를 제거
    • POST: 주어진 표현에 기반을 두고 이 리소스 아래 새 리소스를 생성
    • PUT: 이 리소스의 현재 상태를 주어진 표현으로 대치(전체)
    • PATCH: 이 리소스의 일부 상태를 주어진 표현으로 변경(일부)
    • HEAD: 이 리소스의 표현과 함께 주어질 헤더를 받음(표현은 X)
    • OPTIONS: 이 리소스가 어떤 HTTP 메서드에 응답하는지 알아냄
    • LINK: 다른 리소스를 이 리소스에 연결
    • UNLINK: 다른 리소스와 이 리소스의 연결 관계를 제거
  • 모든 요청은 프로토콜 의미 체계가 동일하지만, 애플리케이션 의미 체계는 다르다.

GET

  • 정보를 요청할 뿐이라 안전한 메서드여야 한다.
  • 리소스 상태를 바꿀 것을 예상해서는 안된다.

DELETE

  • 삭제하는 메서드

멱등성(idempotence)

  • DELETE 요청은 두 번 이상 보내도 한번 보낸것과 같은 결과가 나와야 한다.
  • 지운걸 또 지우려는 요청을 보내도 처음 지웠을 떄와 동일하기 때문이다.
  • 수학 0을 곱하는 것과 같은 이치
  • GET도 마찬가지다. 리소스가 변하지 않으므로
  • PUT도 마찬가지. 같은걸 계속 덮어써도 결과는 동일하므로

POST로 추가하기

  • 새로운 리소스를 생성

PUT

  • 덮어쓰기

PATCH

  • 일부만 수정할 경우
  • 멱등성이 없다.
    • 예를 들어, 특정 값을 1 증가시키는 요청을 보내면 멱등성이 없다.
    • PUT은 리소스 전체상태의 교체기 때문에 이러한 요청이 없다.
    • 특히 PUT은 전체상태를 모르는 상태에서 이렇게 만들기 위해 쓰기도 한다.
    • 반면 PATCH는 현재 상태를 알고 이를 일부 변화시키기 위한 요청
  • 아직 HTTP 명세에 정의되지 않았다.
  • 리소스 간 하이퍼미디어 링크를 관리
  • 멱등하지만, PATCH와 마찬가지로 명세에 정의되지 않아 안전하지 않음
  • GET을 헤더에만 적용하는 느낌이라 안전함
  • GET 대신 쓰더라도 시간이 줄어들진 않지만, 대역폭 사용량은 줄어든다.

OPTIONS

  • 응답 헤더에는 HTTP Allow가 담겨, 해당 리소스가 지원하는 HTTP 메서드를 나열한다.
  • 잘 설계된 API는 이 요청이 없어도 응답에 제공되는 하이퍼미디어 문서로 알게끔 해준다.

오버로드한 POST

  • 사실 온갖 종류의 변화에 다 쓰이는게 POST다.
  • 예를 들어, HTML 폼은 PUT 요청에 보낼 수 없다.

  • HTTP 규격에서 POST는

    폼 전송의 결과와 같이 데이터 블록을 데이터 처리 프로세스에 제공한다.

  • 어떤 데이터든, 어떤 목적이든 POST로 보내는 것이 허용된다는 의미다.
  • 실제로 POST는 프로토콜 의미체계라는 게 존재하지 않으며, 애플리케이션의 의미 체계로만 이해할 수 있다.

어떤 메서드를 사용해야 할까?

  • HTTP의 프로토콜 의미 체계는 HTTP 메서드에 의해 정의된다.
  • 이 정의에는 중복이 많다
    • PUT을 PATCH로, HEAD를 GET으로 대체 가능하다.
    • POST는 모든 것을 대체할 수 있다.
  • HTML 문서가 허용하는 체계는 GET과 POST 뿐이다.
CATALOG
    restful