RESTful API
API 시스템을 구현하기위한 아키텍처(Graphql, SOAP, GRPC 등) 중에 가장 널리 사용되는 형식
(비용이 저렴하고, 학습의 진입장벽이 낮으며, 효율적이기 때문)
REST 특징을 지키면서 API를 제공한다는 의미
가장 기본적이고 널리 통용되는 형식
REST(REpresentational State Transfer)
웹에 존재하는 모든 자원(resorce, ex. 이미지, 동영상, 데이터)에 고유한 URI를 부여하여 자원에 대한 주소를 지정하는 방법론, 또는 규칙
웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 그 리소스에 대한 행위를 HTTP Method로 정의하는 방식. 즉, (HTTP URI로 정의된)리소스를 어떻게 한다(HTTP Method+Payload)는 것을 구조적으로 깔끔하게 표현
- 장점: self-descriptiveness(RESTful API 그 자체만으로도 API의 목적이 쉽게 이해됨)
- 단점: 표준규약이 없어서, 안티패턴(실제 많이 사용되는 패턴이지만 비효율적이거나 비생산적인 패턴)으로 작성되는 경우가 흔함
URI / HTTP Method / Payload 로 구성
URI: 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소
HTTP Method: HTTP Request가 의도하는 action을 정의한 것
Payload: HTTP Request에서 서버로 보내는 데이터(body)
규칙
URI 정보를 명확하게 표현
resource는 명사를 사용
일반적으로 복수형으로 사용
ex) /user/1 --> /users/1
resource에 대한 해위를 HTTP Method(GET,POST,PUT,DELETE)로 표현
URI에 HTTP Method가 포함되면 안됨
ex) delete/user/1(x)
URI에 동사가 포함되면 안됨
ex) user/show/1(x)
resource 사이에 연관관계가 있는 경우
- /리소스/고유ID/관계 있는 리소스
ex) GET /users/{user_id}/profile
파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않음
payload의 포맷은 headers에 accept를 사용
ex) user/1/profile-photo.jpg --> user/1/profile-photo
URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용
URI 마지막 문자로 /를 포함하지 않음
ex) /user/1/ --> /users/1
불가피하게 URI가 길어지는 경우 -을 사용하셔 가독성을 높임(스네이크 케이스, _ 금지)
URI 경로에는 대문자 사용 금지
예시
path parameter
urls.py에 /<파라미터의데이터타입:파라미터명> 경로 설정(ex. /<str:파라미터명>, /<int:파라미터명>)
파라미터명이라는 변수명의 파라미터를 뷰 내 함수에서 인자로 받아올 수 있음(ex. def 함수명(self, request, 파라미터명))
query parameter
url 엔드포인트 끝에 ?파라미터멍1=파라미터내용1&파라미터멍1=파라미터내용2&파라미터멍2=파라미터내용2
파라미터명이라는 변수명의 파라미터를 뷰 내 함수에서 변수로 받아올 수 있음(ex. 변수명=request.GET.get('파라미터명', None))
주로 filtering, ordering, searching 등에서 활용
filtering
ordering
