API ( Application Programming Interface )
두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘
운영체제와 응용 프로그램 사이의 통신에 사용되는 언어나 메시지 형식
client (요청 전송) ↔ API ↔ server (응답 전송)
장점
ex 1 _ 개발자 간의 상황 ( 프론트엔드 - 백엔드 )
client ↔ API ↔ server
Front-End ↔ 데이터를 제공하는 기능 ↔ Back-End
Back-End : 데이터를 저장 보관
Front-End : 백엔드의 데이터를 필요로 함
Front-End 에서 만들어질 응용 프로그램이 Back-End 시스템의 데이터에 접근하고자 하는 상황
> Back-End 는 그러한 요청에 대해 쉽게 데이터를 제공하도록 하는 기능 (API)을 잘 만들어야 하는 것
ex 2 _ 일상생활에서의 상황 ( 현금 출력 )
client ↔ API ↔ server
손님 ↔ ATM 기기 / 은행원 ↔ 계좌
현금 출력하고 싶은 상황일 때
돈은 계좌에 들어있는 상황이므로 ATM 기기 또는 은행원에게 현금 출력을 요구하면 계좌와 연결되어 있는 ATM / 은행원이 출력을 실행해주는 것
HTTP + XML > 메시지를 주고 받는 것처럼 정보 주고 받는 방식 , Web 활용하는 방식
단순 객체 접근 프로토콜을 사용
유연성이 떨어지는 API ( 과거에 더 많이 사용된 API , 무거워서 속도가 떨어짐 )
RPC는 프로토콜 (약속)이므로 소켓 통신으로 구현하기 힘든 기능을 수월하게 구현 가능
다른 컴퓨터의 프로그램의 프로시저를 실행하는 프로그램을 허용하는 프로토콜
확장성 ( 분산 네트워크 환경에서 프로그래밍 하는 것에 용이 , 다양한 언어를 가진 환경에서 쉽게 사용 가능 )
클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송
TCP 연결 기반으로 서버와 클라이언트간의 양방향 통신 가능
JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발
양방향 통신 지원
client app ↔ server
서버가 연결된 client 에 call back message 전송 가능 > REST API 보다 효율적
오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연하며 대표적인 API 구현하는 방식 , 양방향 통신을 지원하는 방식
클라이언트 ( 데이터 형태로 요청 )와 서버는 HTTP 를 사용하여 데이터 요청/전달하는 방식
응용 프로그램이 시스템에 있는 자원 ( 데이터 )을 쉽게 사용하기 위해 시스템이 각 자원에 이름을 붙여 정리해놓은 것
URI : Resource 표현 , 처리 결과 : Status Code 사용
무상태 : 서버가 요청 간에 클라이언트 데이터를 저장하지 않음을 의미
함수 집합 정의
GET / PUT / DELETE
클라이언트가 서버 데이터에 액세스 하는 데 사용할 수 있는 함수
Django 를 기반으로 REST API 서버를 만들기 위한 라이브러리
Back-End API server 개발을 위한 목적으로 사용
DRF 사용 > JSON 응답
다양한 플랫폼의 클라이언트에게 데이터를 제공하는 API 서버 프로젝트가 만들어짐
django / Django REST Framework 차이
ex _ 국가 ) 전국 공공시설 정보 , 대중교통 운행 정보 , 미세먼지 농도 정보 등
ex _ 정부 ) 공공데이터포털 : 국가 기관이 보유한 수많은 데이터를 API 형태로 무료 공개
ex _ 기업 ) 카카오 , 네이버 , 구글 > 무료 Open API 제공 중
유형
Private
기업 내부에 있으며 비즈니스 내에서 시스템과 데이터를 연결하는 데만 사용
Public
누구나 사용 가능 > 제 3자가 API와 상호작용하는 애플리케이션 개발 가능
외부에서 제약 없이 호출할 수 있도록 공개된 API
API를 특정 비즈니스 파트너와 공유하는 API
복잡한 시스템 요구사항이나 동작을 처리하는 API
클라이언트와 서버 API 간 데이터 양식을 맞춰주는 변환기
무조건 모든 데이터를 변환하는 것이 아니라 필요에 따라서 원하는 데이터만 직렬화 하도록 조정 가능
DRF 내에서 데이터를 저장하면 Django의 모델을 통해 저장
model (데이터베이스 테이블을 추상화한 개념 ) 을 ORM ( 파이썬 문법으로 데이터 처리 가능 )을 통해 Django에서의 데이터는 파이썬 객체의 형태로 저장됨
Serialize : 파이썬 데이터 객체 > 문자열 (JSON , dictionary 등)
* JSON , Javescript Object Notation
데이터의 송수신을 자바스크립트 객체로 할 수 있게 하는 문자열 데이터
작성 순서
STEP 1 Model 작성
STEP 2 migration 수행
STEP 3 Serializer 작성 ( Fields 선언 필수 )
STEP 4 View 작성
from rest_framework import serializers
rest_framework의 serializer 클래스 참조
class todoSerializers(serializers.Serializer)
Serializer 상속 받는 경우
모델을 다시 작성해야 해서 같은 내용이 반복되고 코드가 길어져 매우 비효율적
class todoSerializers(serializers.ModelSerializer)
모델에서 이미 모델의 내용을 기반으로 동작하는 serializer 선언 > 간단하게 작업 가능
@api_view와 같이 데코레이터 형태로 API View를 사용
작성하는 것에 있어 간편함
decorater
함수를 꾸미는 역할 , @ 표시와 함께 작성되는 코드
해당 함수에 대한 스타일을 표시해주는 표기법
함수를 인자로 받는 하나의 함수
from rest_framework import viewsets, permissions, generics, status
from rest_framework.reponse import Response
from rest_framework.views import APIView
from rest_framework.decorators import api_view
@api_view(['GET'])
def HelloAPI(request):
return Response("Hello World")
APIView 클래스를 상속 받는 형태로 생성
FBV와 기능적 차이 거의 존재하지 않음
decorater 필요하지 않음
클래스 내에 get / post 따로 정의
> 요청이 GET인지 POST인지 조건문으로 따져볼 필요 X
from rest_framework import viewsets, permissions, generics, status
from rest_framework.reponse import Response
from rest_framework.views import APIView
from rest_framework.decorators import api_view
class HelloAPI(APIView):
def get(self,request):
return Response("Hello World")
API의 정의부터 CS Model별로 작동 방식과 특징을 살펴보았고 , DRF Serializer 와 FBV / CBV 특징까지 기본적인 이론에 관한 것을 바탕으로 스터디 진행