REST
우리가 장고를 통해 BE단에서 하는 것은 RESTful한 API를 만드는 것이다.
"REST스러운 API"을 이해하기 위해서는 "REST"에 대한 이해가 선행되어야 한다.
REST는 기본적으로 "웹에 대한 설계방법론"의 하나이다.
일반적으로 RESTful API에 대한 개발자들의 해석은 수렴되는 반면에 REST자체에 대한 해석은 다양하다.
REST(REpresentational State Transfer의 약자)를 웹페이지의 상태(state)에 대해 유저의 행위로 상태 전이(transfer)가 일어나며, 이때 유저가 받는 상태는 특정한 표현(representational)에 의한다고 보기도 한다.
하지만 개인적으로는 이 해석으로는 REST에 대한 감이 잡히지 않아서 이리저리 찾아본 결과, REST는 아래와 같이 설명할 수 있을 것 같다.
1. Resource (자원)
- HTTP URI
- 서버의 모든 자원은 (고유 ID인) HTTP URI를 가진다
- -> 우리는 Method 행위의 대상인 Resource를 URI로 구별(식별)한다
2. Method (Verb, 행위)
- HTTP Method (자원에 대한 행위)
- GET, POST, PUT, DELETE, FETCH 등
- GET : 해당 리소스의 조회
- POST : 리소스 생성
- PUT : 리소스의_전체적인 수정
- (FETCH : 리소스의_부분적인 수정)
- DELETE : 리소스 삭제
3. Representation (표현)
- HTTP Message Pay Load (=Representation data)
- body에 포함되는 json 등의 형식을 가진 데이터
- POST요청, PUT요청이 대표적
- Representation = Representation data + Representation Meta data
- -> body에 JSON, XML, RSS 등의 형태로 담기는 data
- -> header에 담긴 "content_type"등도 meta data로써 REST의 representation에 해당함
즉, 엄밀히는 JSON등의 형태로 body에 담기는 data 뿐만 아니라 header에 담기는 meta data들도 representation에 해당한다.
아래는 가상의 URI로 REST를 정리한 것이다.
Method | URI | RESOURCE | REPRESENTATION | (<-Pay Load를 위주로.) |
GET | http://test01.com/articles | articles (endpoint) | GET req에 대한 response | |
GET | http://test01.com/articles/10 | articles/10 (=10번째 article) | GET req에 대한 response | |
POST | http://test01.com/articles | articles (endpoint) | POST req의 body에 있는 data, 요청에 대한 response | |
PUT | http://test01.com/articles/10 | articles/10 | PUT req의 body에 있는 data(=수정값) | |
DELETE | http://test01.com/articles/10 | articles/10 | - (req와 response 모두에 data없음) |
단, 모든 경우에 representation meta data는 항상 있다.
meta data의 예로는 "content_type", "status_code" 등이 있다.
REST의 대표적 규칙
- URI는 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP Method로 표현한다.
- URI는 동사보다는 명사를, 대문자보다는 소문자를 사용
http://test01.com/articles/create -> http://test01.com/articles/ (POST요청이면 article생성, GET요청이면 article조회임을 알 수 있음) - 마지막에 '/'를 포함하지 않는다.
http://test01.com/articles/2/ -> http://test01.com/articles/2 - '_' 대신 '-'를 사용한다.
http://test01.com/json_drf -> http://test01.com/json-drf - 파일 확장자는 URI에 포함시키지 않는다.
http://test01.com/photo.jpg -> http://test01.com/photo
RESTful API
RESTful API는 REST를 기반으로 구현한 API를 말한다.
즉, REST 원리 및 규칙을 준수하여 REST API를 제공하는 웹 서비스를 RESTful하다고 하는 것이다.
API란?
어플리케이션 간의 (프로그래밍적)소통을 위해서 서로 약속된 형식
-> 클라이언트-서버 구조에서 API의 주된 사용자는 FE개발자들이다. 따라서, API가 RESTful할수록 BE단의 별다른 설명이 없어도 FE개발자들이 알기 쉬움으로 FE-BE로 구분해 개발하는 환경에서 협업이 용이하다
Restful API를 쓸 때, 우리가 얻을 수 있는 장점은 다음과 같다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
- REST API를 통해 서버단이 의도하는 바를 명확하고, 쉽게 파악할 수 있다.
- 여러 가지 서비스 설계에서 생길 수 있는 문제를 최소화한다.
json과 dictionary
공통점
- key-value 쌍: JSON 및 Python 사전은 모두 데이터를 키-값 쌍으로 구성
- 중첩 구조: 중첩을 지원하여 값이 사전이나 목록 내의 사전이나 목록이 될 수 있음
- key로 접근: 키를 사용하여 데이터에 접근근
차이점
차이점 | JSON | Dictionary | 비고 |
구문 | 특정 구문이 포함된 텍스트 기반 형식 | 자체 구문이 포함된 python 내장 데이터 유형 | JSON의 특정구문이란? : key-value쌍, 구분기호인 쉼표, 객체 중괄호{}, 배열 대괄호[], 문자열 표현 등임 |
데이터 유형 | Dict에 비해 제한적 | 폭넓음 | |
직렬화 | 필요 | 불필요 | |
사용 사례 | 네트워크를 통해 서로 다른 시스템 간의 데이터 교환에 폭넓게 사용됨 | Python 프로그램 내에서만 사용 |
데이터 유형 | JSON | Dictionary |
key | - Key값은 문자열이어야 함 - 큰따옴표로 둘러싸야 함 |
Key값으로는 불변형(immutable) 데이터 타입인 문자열, 숫자, 튜플이 가능 |
value | Value값은 문자열, 숫자, 불리언, 배열, 객체, 또 다른 JSON 등이 가능 | Value값으로는 모든 데이터 타입이 가능하며, 리스트나 다른 사전을 포함할 수 있다 |
참고자료
https://sabarada.tistory.com/27
'TIL' 카테고리의 다른 글
[TIL 2024. 04. 25] Python GIL | 메모리 관리 (0) | 2024.04.25 |
---|---|
[TIL 2024. 04. 24] 컴파일러와 인터프리터 | 정적타입과 동적타입 (0) | 2024.04.24 |
[TIL 2024. 04. 22] 개념정리 (0) | 2024.04.22 |
[TIL 2024. 04. 19] 개인과제 오류 수정 (3) (0) | 2024.04.21 |
[TIL 2024. 04. 18] django 프로젝트시 주의점 (0) | 2024.04.19 |