01. API?
API = Application Programming Interface
운영체제와 응용프로그램 사이의 통신에 사용되는 언어나 메시지 형식
예시
1. 식당
1-1. 점원은 고객에게 주문을 받아 요리사에게 전달
1-2. 요리사에게 음식을 받아 고객에게 전달
=> 점원은 중간 전달자의 역할을 담당한다 (API의 역할)
2. 기상청 소프트웨어시스템
2-1. 기상청 시스템에 일일 기상 데이터가 들어옴
2-2. 휴대폰의 날씨앱 : API를 통해 기상청 시스템과 대화해 앱에 최신 날씨 정보 표시
=> 고객이 날씨앱을 키면 API는 기상청 시스템이 있는 기상 데이터를 가져와 고객에게 보여줌
3. 네비게이션 앱
누군가가 만들어 놓은 지도API 를 가져오면 앱에서 지도 정보를 완성할 수 있다.
4. 웹툰 서비스
4-1. 사용자가 웹툰을 요청한다
4-2. 웹툰서비스 api는 웹툰 서버에 있는 목록 중 사용자가 원하는 웹툰을 준다.
=> 이처럼 누군가가(본인)이 만들어 놓은 것(API)을 사용해 보여준다고 생각하면 된다.
01 - 1. 작동 방법
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명
클라이언트 : 요청을 보내는 애플리케이션
서버 : 응답을 보내는 애플리케이션
SPAP API
단순 객체 접근 프로토콜을 사용
- 클라이언트와 서버는 XML을 사용해 메시지 교환
- 과거에 더 많이 사용되었으면 유연성이 떨어지는 API
RPC API
원격 프로시저 호출이라고 부름
- 클라이언트가 서버에서 함수나 프로ㅅ저를 완료하면 서버가 출력을 클라이언트로 다시 전송
- 다른 컴퓨터의 프로그램의 프로시저를 실행하는 프로그램 허용하는 프로토콜
- 분산 네트워크 환경에서 더 편하게 프로그래밍하기 위해 등장
- 다양한 언어를 가진 환경에서 쉽게 확장 가능
Websocker API
JSON 객체를 사용해 데이터를 전달하는 또 다른 최신 웹 API개발
- 클라이언트 앱과 서버 간의 양방향 통신을 지원
- 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적
REST API
오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API
Representtational State Transfer의 줄임말로 API를 구현하는 방식 중 가장 대표적임
- 클라이언트 앱과 서버간의 양방향 통신을 지원
- 클라이언트가 서버에 요청을 데이터로 전송
- 서버가 이 클라이언트 입력을 사용해 내부 함수를 시작하고 출력 데이터를 다시 반환
- 클라이언트가 서버 데이터에 엑세스하는 데 사용할 수 있는 함수 집합을 정의
- 클라이언트와 서버는 HTTP를 사용해 데이터를 교환
- 주된 특징은 무상태 => 서버가 요청 간에 클라이언트 데이터를 저장하지 않음을 의미
Open API
누구나 쓸 수 있도록 공개된 API대표적으로 정부는 공공데이터포털을 통해 국가기관이 보유한 수많은 데이터를 aPI형태로 무료 공개하고 있음
01 - 2. 유형
1. Private
기업 내부에 있으며 비즈니스 내에서 시스템과 데이터를 연결하는 데만 사용
2. Public
누구나 사용가능. 제 3자가 API와 상호 작용하는 애플리케이션 개발 가능
3. Partner
B2B 파트너십을 지원하기 위해 권한이 부여된 외부 개발자만 액세스 가능. API를 특정 비즈니스 파트너와 공유하는 API
4. 복합
두 개 이상의 서로 다른 API를 결합해 복잡한 시스템 요구 사항이나 동작을 처리하는 API
01 - 3. 장점
서비스가 어떻게 구현되었는지 몰라도 그대로 서비스를 가져다 사용할 수 있음
즉, 매번 새로운 개발을 할 필요 없이 이미 만들어 놓은 기능을 그대로 가져다 쓰는 것!
- 개발 시간 감소
- 비용 절감
- 누구나 쉽게 이해할 수 있어 협업에 용이하고 유지보수 수월
02. DRF (Django REST Framework)
Django를 기반으로 REST API 서버를 만들기위한 라이브러리
자체적인 템플릿에 바로 데이터를 전달해주던 프로젝트에서 DRF를 사용하면 JSON같은 양식으로
다양한 플랫폼의 클라이언트에게 데이터를 제공하는 API 서버 프로젝트가 만들어진다.
02 - 1. DRF Serializer
사전적 정의 : 직렬화
Django 프로젝트에서 만든 모델로부터 뽑은 queryset인 모델 인스턴스를 JSON 타입으로 바꾸는 것
DRF 내에서 데이터를 저장하면 Django의모델을 통해 저장
모델은 데이터베이스 테이블을 추상화한 개념이고 ORM을 통해 파이썬 문법으로 데이터를 처리할 수 있기 때문에 Django에서의 데이터는파이썬 객체의 형태로 저장
이런 데이터를 클라이언트에 보내주는 것이 API의 역할
=> 파이썬 데이터 객체를 문자열로 변환하는 작업이직렬화 (Serializer)
작성순서
1. 모델작성
2. 마이그레이션 수행 (makemigrations - migrate)
3. 시리얼라이저 작성 (serializers.py)
4. 뷰 작성
=> 모델 데이터의 어떤 속석을 JSON에 넣어줄지 선언해야함 (모든 속성을 안넣을 수 있음)
=> 시리얼라이저에도 필드 선언 필수!from rest_framework import serializers
class todoSerializers(serializers.Serializer) :
Serializer를 상속받으면 모델을 또 작성해야해서 같은 내용이 반복되고 코드가 길어져 매우 비효율적
class todoSerializers(serializers.ModelSerializer) :
모델의 내용을 기반으로 동작하는 시리얼라이저 필드 선언을 이미 모델에서 했으므로 간단하게 작업 가능
02 - 2. DRF FBV, CBV
FBV (함수형 뷰, Function Based View)
함수형 뷰에서는@api_view와 같이 데코레이터 형태로 API View를 사용데코레이터
함수를 꾸미는 역할로 @ 표시와 함께 작성되는 코드
해당 함수에 대한 스타일을 표시해주는 표기법
함수를 인자로 받는 하나의 함수라고 볼 수 있다
FBV 코드 예시
from rest_framework import viewsets, permissions, generics, status
from rest_framework.response 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");
CBV (클래스형 뷰, Class Based View)
클래스형 뷰는 뷰를 만들 때 APIView 클래스를 상속 받는 형태로 생성
함수형 뷰와의 차이점
=> 클래스 내에 get과 post를 따로 정의하기 때문에 데코레이터 필요없음
CBV 코드 예시
from rest_framework import viewsets, permissions, generics, status
from rest_framework.response import Response
from rest_framework.views import APIView
from rest_framework.decorators import api_viewclass HelloAPI(APIView) :
def get(self, request) :
return Response("Hello World")
DRF 설치 및 등록 방법
1. pip install djangorestframework
2. INSTALLED_APPS =['rest_framwork'](settings.py)
실습은 다음주에 하도록 하겠다.
