본문 바로가기

study/Web

[WEB] REST API

0. API

어플리케이션과 프로그래밍으로 소통하는 방법

  • Web API: 웹 어플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세. 현재 웹개발은 추가로 직접 모든 것을 개발하지 않고 여러 Open API를 가져와서 활용하는 추세 (모든 api가 다 오픈되어있는건 아님)
  • 이제는 사용자에게 HTML 파일을 보내는게 아니라 JSON 파일을 보냄
  • JSON 쓰는 이유? 데이터 전송을 위해 만들어진 형식이기 때문
  • HTML은 사람 보라고 만든 문서

 

1. REST API 개념

  • REST: '자원'과 '주소'를 지정하는 방법
    • 웹 설계 상의 장점을 최대한 활용할 수 있는 아키텍처 방법론(규약이 x - 꼭 지키지 않아도 된다)
    • 네트워크 아키텍쳐 원리의 모음
      1. 자원을 정의 (data에 어떻게 접근할 것인가)
      2. 자원에 대한 주소를 지정하는 방법
    • 구성: 자원 / 행위 / 표현

1-1. 자원(URI)

Uniform resource identifier(통합 자원 식별자) - 인터넷의 자원을 나타내는 유일한 주소

하위 개념: URL, URN

  • URL
    • 통합 자원 위치(Uniform resource locator)
    • 네트워크 상에 자원이 어디 있는지를 알려주기 위한 '약속'
    • 자원은 HTML 페이지, CSS 문서, 이미지 등이 될 수 있음
    • '웹 주소' 또는 '링크'라고 불림
  • URN
    • 통합 자원 이름 (자원의 인식표. 주민등록증)
    • URL과 달리 자원의 위치에 영향을 받지않는 유일한 이름 역할을 함(독립적 이름)
    • 예시: ISBN (국제표준도서번호)
  • URN은 자원의 id 정의하고 URL은 자원을 찾는 방법을 제공 -> 상호보완적
  • 일반적으로 URL은 URI를 통칭하는 말로 사용하기도 함 (URN을 사용하는 비중이 매우 적기 때문에)
    • 모든 URL은 URI이다. (O)
    • 모든 URI는 URL이다. (X)
  • URI 구조
    • Protocol(Scheme): 일종의 약속
    • Host: IP 주소가 들어감
    • Port: 통로라고 생각하면 됨(기술적인 gate) 장고의 경우 8000
    • Path: 자원의 경로
    • PATH 까지가 URL이 표현할 수 있는 개념. query와 fragment는 URI에 속하는 개념!! 전체는 당연히 URI에 포함됨
    • Query: ? 뒤쪽으로 key=value 형식으로 붙는거. 보통 검색할 때
    • Fragment: 대주제(문서의 특정부분을 보여줌) - 서버로 보내는게 아니라 브라우저에게 보내는 것!
  • URI 설계 주의사항
    • 언더바가 아닌 하이픈을 사용(for 가독성)
    • 소문자 사용(대소문자에 따라 다른 자원으로 인식)
    • 파일 확장자는 포함하지 x

1-2. 행위(HTTP Method)

  • HTTP: HTML 문서와 같은 자원들을 가져올 수 있도록 해주는 프로토콜(규칙)
  • 웹에서 이루어지는 모든 데이터 교환의 기초
  • 이 약속은 클라이언트 - 서버 프로토콜에 의해 이루어짐
  • HTTP 특징
    • 비연결지향: 서버는 응답 후 접속을 끊음
    • 무상태: 접속이 끊어지면 클라이언트와 서버 간의 통신이 끝나며 상태를 저장 x (로그인 등의 상태)
  • HTTP Method
    • 자원에 대한 행위
    • HTTP는 HTTP Method를 정의하여 주어진 자원에 수행하길 원하는 행동을 나타냄(GET, POST method 등을 이용)
    • 의미론적으로 행위를 규정하기 때문에 실제 그 행위 자체가 수행됨을 보장하지 않음(ex. GET 요청으로 글 삭제도 할 수 있긴 하다)
    • HTTP Verbs라고 함
  • HTTP Method 종류: 이젠 URL로 자원에 대한 행위를 결정하는게 아니라 메서드를 통해 결정할 것!
    1. GET: 특정 자원의 표시를 요청. 오직 데이터를 받기만 함
    2. POST: 서버로 데이터를 전송. 서버에 변경사항을 만듦
      • 기존에는 POST로 C, U, D 다 수행했는데 이제는 U - PUT, D - DELETE 요청이 할 거임!
    3. PUT: 요청한 주소의 자원을 수정
    4. DELETE: 지정한 자원을 삭제
  • QUIZ. 다음 uri는 RESTful 철학을 지켰는가?
    1. GET /articles/1/read/: X. URI에 불필요한 정보(행위 표현)가 포함되기 때문
    2. GET /articles/1/delete/: X. 삭제를 원하는데 메서드가 GET이므로 DELETE /articles/1/ 가 되어야 함

1-3. 표현(Representations)

JSON 객체로 표현할 것이다!

  • JSON: Javascript object notation
    • 가벼운 데이터 교환 포맷 중 하나
    • 자바스크립트 객체 문법을 따르며(완전 동일하진 x) 구조화된 데이터 표현하기 위한 문자 기반 데이터 포맷
    • 일반적으로 웹 어플리케이션에서 클라이언트로 데이터를 전송할 때 사용
  • JSON 특징
    • 사람이 읽고 쓰기 쉬움 + 기계가 파싱(해석&분석)하고 만들어 내기 쉬움
    • 파이썬의 dictionary처럼 C 계열의 언어가 갖고 있는 자료 구조로 쉽게 변환할 수 있는 key-value 의 구조로 되어 있음
    • 자바스크립트가 아니어도 사용할 수 있음!
  • 파싱: 문자열 자료를 우리가 쓸 수 있는 JSON 객체로 변환하는 것
  • 결국 Backend는 JSON 객체만 보내주는 역할, Client 부분은 Frontend framework를 이용할 것!

 

2. REST API 특징

  1. 무상태성 (Stateless): 세션, 쿠키 등에 상태 정보를 따로 저장하여 관리하지 않고 API 요청에 대한 처리만 수행
  2. 캐시가능 (Cacheable): Last-Modefied나 E-Tag를 이용한 캐싱 등 기본적으로 웹 HTTP 프로토콜이 가지는 캐싱 기능 활용
  3. 자체 표현 구조(Self-descriptiveness): REST API의 규격, 메시지만 보고도 동작에 대한 이해를 쉽게 할 수 잇음
  4. Client-Server 구조: REST API 서버는 API 제공, 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 역할이 분리되어 Client와 Server 간의 상호 의존성이 줄어듦
  5. 계층형 구조: 보안, 로드 밸런싱, 암호화, Proxy, API gateway 등 추가적인 계층을 구축하는 데 구조상 유연함을 가짐