[Django REST] RESTful API 소개

지니🧸·2022년 10월 18일
0

Django REST

목록 보기
1/5

RESTful API란 무엇인가요?

Restful API: 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스


API란?

Application Programming Interface (API): 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙 정의

  • 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성
    • (예) 근무 시간 기록 애플리케이션은 직원의 전체 이름과 날짜 범위를 요청하는 API 표시; 이 정보가 수신되면 내부적으로 직원의 근무 시간 기록을 처리 & 해당 날짜 범위에서 근무시간 반환
  • 웹 API = 클라이언트와 웹 리소스 사이의 게이트웨이

클라이언트

  • 클라이언트: 웹에서 정보에 액세스하려는 사용자
    • API를 사용하는 사람이거나 소프트웨어 시스템일 수 있음
    • (예) 개발자는 날씨 시스템에서 날씨 데이터에 액세스하는 프로그램 작성; 사요자는 날씨 웹사이트에 방문할 때 브라우저에서 동일한 데이터에 엑세스

리소스

  • 리소스: 다양한 애플리케이션이 클라이언트게에 제공하는 정보
    • 이미지, 동영상, 텍스트, 숫자 등 모든 유형의 데이터
  • 서버: 클라이언트에 리소스를 제공하는 시스템
  • 조직은 API를 사용해 리소스 공유 & 보안, 제어 및 인증 유지 --> 웹 서비스 제공
  • API는 특정 내부 리소스에 액세스할 클라이언트 결정에 도움 됨

REST란?

Representational State Transfer(REST): API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍쳐

  • 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어짐
  • 대규모 고성능 통신의 안정적 지원 가능
  • 모든 API 시스템 파악, 여러 플랫폼 사용 가능

REST 아키텍처 스타일의 원칙

균일한 인터페이스

  • 모든 RESTful 웹서비스 디자인의 기본
  • 서버가 표준 형식으로 정보를 전송함을 나타냄
  • 표현: 형식이 지정된 리소스
    • 이 형식은 서버 애플리케이션의 리소스의 내부 표현과 다를 수 있음
      • (예) 서버는 데이터를 텍스트로 저장하지만 HTML 표현 형식으로 전송할 수 잇음
  • 균일한 인터페이스의 4가지 아키텍처 제약 조건
    (1) 요청은 리소스를 식별해야 함 > 균일한 리소스 식별자 사용
    (2) 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 갖고 있음.
    (3) 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보 수신. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지 전송
    (4) 클라이언트는 작업을 완료하는데 필요한 다른 모든 관련 리소스에 대한 정보 수신. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송.

무상태

무상태: REST 아키텍처에서 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법

  • 클라이언트는 임의의 순서로 리소스 요청 가능
  • 모든 요청은 무상태이거나 다른 요청과 분리
  • 이 REST API 설계 제약 조건은 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미

계층화 시스템

계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결 할 수 있고 서버로부터도 응답 받음.

  • 서버는 요청을 다른 서버로 전달할 수도 있음
  • 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스 설계 가능
    • 이러한 계층은 클라이언트에 보이지 않는 상태로 유지됨

캐시 가능성

  • 캐싱 지원됨
    • 캐싱: 서버 응답 시간을 개선하기 위해 클라이언트/중개자에 일부 응답을 저장하는 프로세스
      • (예) 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트의 경우, 새로운 웹사이트 페이지를 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 함 > 이를 피하기 위해 클라이언트는 첫번재 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지 사용
  • RESTful 웹 서비스는 캐시 가능/캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱 제어

온디맨드 코드

  • 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정 가능
  • (예) 웹사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시
    • 서버에서 전송한 코드로 인해 이 작업 수행 가능

RESTful API의 장점

  • 확장성
    • REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정 가능
    • 무상태 - 서버가 과거 클라이언트 요청 정보를 유지할 필요 없어서 서버 로드 제거
    • 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로/완전히 제거
    • 위의 기능들은 성능을 저하시키는 통신 병목 현상을 일으키지 않음 > 확장성 지원
  • 유연성
    • 완전한 클라이언트-서버 분리 지원
    • 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리함
    • 서버 애플리케이션의 플랫폼/기술 변경은 클라이언트 애플리케이션에 영향 X
    • 애플리케이션 함수를 계층화하는 기능 > 유연성 향상
      • (예) 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층 변경 가능
  • 독립성
    • REST API는 사용되는 기술과 독립적임
    • API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션 모두 작성 가능
    • 통신에 영향 없이 양쪽의 기본 기술 변경 가능

RESTful API 작동 원리

Restful API에는 다음과 같은 주요 구성요소를 포함하는 요청 필요

고유 리소스 식별자

  • 서버는 고유한 리소스 식별자로 각 리소스 식별
  • 주로 URL (Uniform Resource Locator)을 사용하여 리소스 식별 수행
    • URL: 리소스에 대한 경로 지정
      • 웹페이지를 방문하기 위해 브라우저에 입력하는 웹사이트 주소와 유사
      • aka 요청 엔드포인트
      • 클라이언트가 요구하는 사항을 서버에 명확히 지정

메서드

  • 개발자는 종종 HTTP (Hypertext Transfer Protocol)을 사용하여 RESTful API 구현
  • HTTP 메서드: 리소스에 수행해야 하는 작업을 서버에 알려줌
    • GET 메서드
      • 클라이언트는 GET으로 서버의 지정된 URL에 있는 리소스에 엑세스
      • GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송 > 전송 전에 데이터를 필터링하도록 서버에 지시 가능
    • POST 메서드
      • 서버에 데이터 전송
      • 요청 & 데이터 표현 포함
      • 부작용: 동일한 POST 요청을 여러번 전송하면 동일한 리소스 여러번 생성
    • PUT 메서드
      • 서버의 기존 리소스 업데이트
      • POST와 차이: 동일한 PUT 요청을 여러번 전송해도 결과는 동일
    • DELETE 메서드
      • 리소스 제거
      • 서버 상태 변경할 수 있음
      • 요청이 성공하려면 사용자의 인증 필요

HTTP 헤더

요청 헤더: 클라이언트와 서버 간에 교환되는 메타데이터
(예) 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보 제공

  • 데이터: POST, PUT 등의 HTTP 메서드가 성공적으로 작동하기 위한 데이터 포함 가능
  • 파라미터: 수행해야 할 작업에 대한 자세한 정보를 서버에 제공함
    • URL 세부정보를 지정하는 경로 파라미터
    • 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터
    • 클라이언트를 빠르게 인증하는 쿠키 파라미터

RESTful API 서버 응답

서버 응답의 주요 구성 요소:

상태 표시줄

상태 표시줄: 요청 성공/실패를 알리는 3자리 상태 코드 포함

  • 200 - 일반 성공 응답
  • 201 - POST 메서드 성공 응답
  • 400 - 서버가 처리할 수 없는 잘못된 요청
  • 404 - 리소스 찾을 수 없음

메시지 본문

응답 본문: 리소스 표현 포함

  • 서버는 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택
  • 클라이언트는 데이터 작성 방식을 일반 텍스트로 정의하는 XML/JSON 형식으로 정보 요청 가능
    • (예) 클라이언트가 John라는 사람의 이름과 나이를 요청하면 서버는 다음과 같은 JSON 표현 반환 > '{"name":"John", "age":30}'

헤더

응답에는 응답에 대한 헤더 (메타데이터) 포함됨
헤더:

  • 응답에 대한 추가 컨텍스트 제공
  • 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보 포함

RESTful API 인증 방법

RESTful 웹 서비스는 응답을 보내기 전에 먼저 요청을 인증해야 함

  • 인증: 신원을 확인하는 프로세스
    • 클라이언트는 신뢰를 구축하기 위해 서버에 자신의 신원을 증명해야 함

RESTful API의 4가지 일반적인 인증 방법:

HTTP 인증

HTTP는 REST API를 구현할 때 직접 사용할 수 있는 일부 인증 체계 정의
체계 중 두가지:

  • 기본 인증: 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송
    • 안전한 전송을 위해 base64로 인코딩
      • base64: 사용자 이름과 암호 페어를 64자의 세트로 변환하는 인코딩 기술
  • 전달자(bearer) 인증: 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스
    • 전달자 토큰: 일반적으로 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열
    • 클라이언트는 리소스에 액세스하기 위해 요청 헤더에 토큰을 넣어 전송

API 키

API 키

  • REST API 인증을 위한 옵션
  • 서버는 고유하게 생성된 값을 최초 클라이언트에 할당
  • 클라이언트는 리소스에 액세스하려고 할 때마다 고유한 API 키를 사용하여 본인 검증
  • 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약 > 덜 안전함

OAuth

  • 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰 결합
  • 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰 요청
  • 특정 범위와 수명으로 언제든지 토큰 확인 가능

참고: AWS 문서 - RESTful API란 무엇입니까?

profile
우당탕탕

0개의 댓글