지금까지 해왔던 장고 프로젝트는 전부 DTL을 이용해서 서버 쪽에서 템플릿을 데이터와 함께 렌더링 해서 완성한 후 그 템플릿을 Response로 제공하는 방식으로 진행했다.

이러한 방식을 서버 쪽에서 렌더링을 한다고 하여 Server Side Rendering 줄여서 SSR이라고 부른다.
또한 이러한 방식은 유저가 페이지를 요청할 때 마다 서버에서 Rendering을 해주기 때문에 페이지가 여러개다.
그래서 페이지가 여러개로 이루어진 어플리케이션이라는 뜻으로 Multi Page Application 줄여서 MPA라고 부른다.
SSR, MPA 방식은 필연적으로 페이지를 요청할 때 마다 새로고침 같은 페이지 이동 이펙트가 동반된다.
무엇보다 이러한 방식은 Web App으로써 나중에 모바일 버전으로 구현한다고 했을 때 레이아웃과 디자인 적응에 따른 조정이 필요하다.(데스크톱 상에서 페이지가 보여질 것을 염두해두고 데이터를 전달했기 때문에)

만약 사용자에게 처음 서버에 접속하면 단 하나의 템플릿만을 전달하고 그 템플릿 안에서 페이지를 이동할 필요가 있을 때마다 서버에 데이터만 요청하고 받은 데이터로 페이지를 생성하면 페이지 이동 이펙트가 사라지지 않을까?
이렇게 작동하는 방식을 클라이언트 쪽에서 렌더링을 한다. 그리고, 페이지 하나로 이루어진 어플리케이션이다라는 의미로 각각 Client Side Rendering(CSR), Single Page Application(SPA)라고 한다.
API(Application Programming Interface)는 이름 그대로 앱과 앱 사이에 프로그래밍적으로 소통할 수 있는 인터페이스를 의미한다.
아까 CSR 방법에서 데이터만을 제공하는 서버를 API Server라고 부르는데 클라이언트 사이드의 React나 Vue.js등으로 작성된 웹 페이지 앱이 서버라는 앱으로부터 데이터와 기능을 표준화된 형식으로 제공받기 때문에 API Server라고 부른다.
반면 일반적으로 정적인 웹 페이지를 저장하고있으며, 사용자의 요청에 따라 렌더링 해서 웹 페이지를 직접 전달하는 서버를 Web Server라고 부른다.
CSR을 사용한다면 보여지는 쪽의 구현을 프론트엔드가 담당하고 백엔드는 데이터만 전달하면 되기 때문에 백엔드 하나만 구현해놓으면 데스크톱, 핸드폰, 워치 등등의 화면은 프론트가 구현하면 되기 때문에 유연성이 대폭 늘어난다는 장점이 있다.
REST란 컴퓨터 네트워크 상에서 리소스의 상태를 전달하기 위한 표현 방법이다.
Representational State Transfer 이름대로 클라이언트와 서버 간에 리소스를 전송할 때(Transfer) 리소스의 표현 방식(Representational)과 리소스의 상태를 표현(State)하는 가이드를 제공한다.
아래의 두 가지 원칙을 준수해야 한다.
1. URI는 정보의 자원을 표현해야 한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다.
REST API의 설계 규칙
1. URI는 명사를 사용한다.(리소스명은 동사가 아닌 명사를 사용해야 한다.)
1-1. 아래와 같은 동사를 사용하지 말 것/getAllUsers
/getUserById
/createNewUser
/updateUser
/deleteUser2. 슬래시( / )로 계층 관계를 표현한다.
3. URI 마지막 문자로 슬래시 ( / )를 포함하지 않는다.
4. 밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용한다.
5. URI는 소문자로만 구성한다.
6. HTTP 응답 상태 코드 사용
- 클라이언트는 해당 요청에 대한 실패, 처리완료 또는 잘못된 요청 등에 대한 피드백을 응답 상태 코드를 통해 받아야 한다.
7. 파일확장자는 URI에 포함하지 않는다.
RESTful API는 이러한 REST 원칙을 따르는 API 서버를 의미한다.
RESTful API Server는 데이터를 표현하는 주된 방식으로 JSON을 사용한다.
JSON은 JavaScript Object Notation의 약자로 자바스크립트 형식으로 작성된 객체 표현 방식이라는 뜻이다.
키-벨류 형식의 구조이며 벨류에 또다른 객체가 들어올 수 있다.
문자는 "로 묶여야 하며 true, false, 숫자 등을 사용할 수 있다.
Django-Seed는 Django 프레임워크를 사용하는 개발자들이 데이터베이스에 테스트 데이터를 쉽게 생성하고 관리할 수 있도록 돕는 라이브러리다.
이 라이브러리를 사용하면 임의의 데이터를 생성하여 모델 인스턴스를 자동으로 채울 수 있으며, 이는 개발 과정에서 데이터베이스를 테스트하거나 프로토타입을 만드는 데 유용하다.
pip install django-seed 를 통해 다운로드# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
# third-party(법률 용어로 제 3자 정도의 의미를 가짐.
# 예를 들어, Google Maps API를 웹사이트에 통합하는 경우,
# 웹사이트 개발자는 웹사이트를 만들고,
# Google은 Google Maps API를 제공하므로
# Google이 이 문맥에서 'third-party'라고 불림.)
"django_seed",
"rest_framework",
# local
'api_pjt.apps.ApiPjtConfig',
'articles.apps.ArticlesConfig',
]
python manage.py seed articles --number=30 를 통해 데이터 시딩
REST 원칙을 따르려면 JSON 형태로 데이터를 줘야 한다.
def json_01(request):
articles = Article.objects.all()
json_articles = []
for article in articles:
json_articles.append(
{
"title": article.title,
"content": article.content,
"created_at": article.created_at,
"updated_at": article.updated_at,
}
)
# safe=False는 제공하는 데이터가 딕셔너리 형식이 아닐 수 있다는 의미이다.
return JsonResponse(json_articles, safe=False)

장고 ORM의 결과는 쿼리셋 객체이기 때문에 이 객체를 바로 클라이언트에게 전송할 수 없다.
위 코드는 수작업을 통해 JSON으로 변환하여 응답하는 코드이다.
사용자가 직접 이렇게 로직을 작성하여 JSON 형태로 만들수도 있지만 장고는 쿼리셋 객체를 JSON 형태로 직렬화하는 모듈을 제공한다.
직렬화?
- 객체 또는 데이터 구조를 저장, 전송을 위해 다른 포맷으로 변경하는 것
→ 데이터의 구조는 유지하면서 추후 재구성이 가능한 포맷으로 변환- 현재 Python 객체 형태인 Queryset 혹은 Model의 Instance를 전송 가능한 형태로 직렬화를 통해 JSON, XML, YAML 등의 형태로 변환하는 것
from django.core import serializers
def json_02(request):
articles = Article.objects.all()
res_data = serializers.serialize("json",articles)
# content_type="application/json"은 이 응답이 json 형태라는 것을 명시함
# 실제 HTTP response 내용에 적혀질 내용
# serializers가 개발자 입장에서는 직렬화를 잘 해주지만 유연하지 않다(커스텀이 불가)는 단점이 있음
# 유연함이 중요하기 때문에 모델에 종속적이지 않고 유연하지만 사용하기 편한 serializers가 필요
# => Django REST Framework의 탄생
return HttpResponse(res_data, content_type="application/json")

장고에서 제공하는 serializers를 사용하면 위 그림처럼 쿼리셋 혹은 모델 인스턴스를 JSON형태로 변환하여 제공한다.
위 코드의 주석에도 적어놨지만 Serializer를 사용하면 커스텀이 어렵다는 단점이 있다.
만약 쿼리를 통해 조회된 쿼리셋에서 각 데이터를 기반으로 새로운 연산을 하여 제공하거나,
쿼리셋에서 필요한 데이터만 제공하고 싶다면 Serializer로 직렬화된 JSON 데이터에서 또 데이터를 추출하여 처리 후 응답으로 보내야한다.
DRF는 Django Rest Framework의 약자이다.
장고로 RESTful API 서버를 만들기 위해 사용하는 장고의 라이브러리이다.
장고 사용자를 타겟으로 만들어졌기 때문에 Form, Model Form과 비슷한 문법을 가진다.
그렇다면 이 DRF는 어떻게 사용하는걸까?
pip install djangorestframework를 입력하여 DRF를 설치한다.# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
# third-party
"django_seed",
"rest_framework",
# local
'api_pjt.apps.ApiPjtConfig',
'articles.apps.ArticlesConfig',
]
from rest_framework import serializers
from .models import Article
class ArticleSerializer(serializers.ModelSerializer):
class Meta:
model = Article
fields = "__all__"
from rest_framework.decorators import api_view
from rest_framework.response import Response
from .serializers import ArticleSerializer
@api_view(["GET"])
def json_drf(request):
articles = Article.objects.all()
serializer = ArticleSerializer(articles, many=True)
return Response(serializer.data)
API 서버를 개발하고 나면 서버가 정상 작동하는지, 결과가 정확한지 등을 확인하기 위해 해당 API에 요청을 보내는 툴이 필요하다.
Postman은 개발자가 API를 디자인, 테스트, 문서화, 공유를 할 수 있도록 도와주는 소프트웨어이다.
API 테스트, 환경 관리, 협업 등을 위한 강력한 기능을 제공하여 보다 효율적으로 API를 개발하고 테스트 할 수 있게 도와준다.



메소드, 쿼리 스트링, 헤더 등의 설정을 수정하여 요청을 보낼 수 있고 요청을 통해 받은 데이터를 raw하게 볼 수도 있으며 헤더도 확인 가능하다.