Django는 파이썬으로 구현하는 프레임워크로서, MVT(Model - View - Temlplate)로 웹페이지를 만든다.
django - views.py
django를 통해 만들고자 하는 db를 구성하기 위해 models.py를 만들어도 보고 C.R.U.D 역시 만들어 보았다.
C.R.U.D
Create, Read, Update, Delete 의 앞글자를 따서 만든 크루드는 데이터를 처리하기 위해 필요한 기능들이다. 가장 간단하면서도 중요한 요소들이다.
Create - 새로운 정보를 생성한다는 의미이다.(SQL - INSERT)
Create
-> Drink.objects.create(name='아이스아메리카노', 칼럼명)
Read - 기존에 있는 정보를 가져온다는 의미(SQL - SELECT)
Read
-> Drink.objects.get(id=1)
-> Drink.obejcts.filter(name='쿨라임피지오')
Update - 수정 또는 갱신(SQL - Update)
Update
1.
a = Categry.objects.get(id = 1) 가져오고 싶은 id값을 a에 저장 해준다.
a.(바꾸고 싶은 칼럼 name) = 바꾸고 싶은 내용
a.save() -> 저장해주어야지 바뀐다.
2.
Category.objects.filter(id=1).update(바꾸고싶은 column명 = '바꾸고 싶은 내용')
하면 1 or 0 을 돌려준다. 1 = True 0 = False
Delete - 제거(SQL - DELETE)
a = Category.objects.get(id=1) 지우고 싶은 내용을 a에 객체저장해주고
a.delete() -> 끝
이렇게 django에서 가장 기본이 되는 C.R.U.D(크루드)를 해보았다.
그리고 이 크루드를 http 에서는 POST, GET, DELETE, PUT, PATCH 로 구현할 수있다.
GET - 어떤 데이터를 받는 메소드, 데이터는 변경되지 않는다.
POST - 서버 혹은 db에게 resource를 생성해달라고 요청 하는것
Delete - 데이터를 지울때 사용하는 메소드
PATCH - 서버 혹은 db에 resource의 업데이트를 요청하는 것
PUT - 서버 혹은 db에 리소스의 업데이트 하거나, 없으면 새로운 resource를 만드는 것
POST VS PUT
POST와 PUT은 C.R.U.D로직 중 Create와 Update의 속성을 가진 http 메소드 입니다.
이 차이를 알기 위해선 REST(Representarional State Transfer)를 알아야 한다. - 이 둘은 REST 에서 사용되는 메소드 이기 때문이다.
REST
이미지를 보면 우리가 views.py로 구현하고 shell에서 수십번을 두들 기면서 본 GET, POST, PUT, DELETE 가 있다.
위키백과
REST(Representational State Transfer)는 월드와이드웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식이다. 이용어는 로이 필딩의 박사학위 논문에서 소개 되었다.
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다.(네트워크 아키텍처 원리 - resource를 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다.)
간단히 말하면 웹 상의 자료를 HTTP위에서 SOAP나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.
(SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP(w3에서 정보를 주고 받을 수 있는 통신 규약), HTTPS(HTTP의 보안이 강화된 버전), SMTP(인터넷에서 이메일을 보내기 위해 이용되는 프로토콜)등을 통해 XML(W3C에서 개발된 다른 특수한 목적을 갖는 마크업 언어)기반의 메세지를 컴퓨터 네트워크 상에서 교환하는 프로토콜)
이러한 필딩의 REST 원리를 따르를 시스템은 종종 RESTful이란 용어로 지정된다.
MDN
REST는 효율적, 안정적이며 확장가능한 분산시스템을 가져올 수 있는 소프트웨어 아키텍쳐 디자인 제약의 모음을 나타냅니다. 그리고 그 제약들을 준수 했을 때 그 시스템은 RESful 하다고 일컬어 집니다.
REST의 주요한 목표
- 구성요소 상호작용의 규모 확장성(scalability of component interactions)
- 인터페이스의 범용성(Generality of interface)
- 구성 요소의 독립적인 배포(Independent deployment of components)
- 중간적 구성요소를 이용해 응답 지연 감소, 보안을 강화, 레거시 시스템을 인캡슐레이션
REST 아키텍쳐에 적용하는 6가지 제한 조건
- UNiform(유니폼 인터페이스)- URL로 지정한 리소스에 대한 조직을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
- 무상태(stateless) - 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안된다.
- 캐시처리기능 - 가장 큰 특징 중 하나로서 HTTP라는 웹표준을 그대로 사용한다.
- 계층화 - 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는데 유용하다.
- Self-description - REST API에 메세지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어있다는 것
- 클라이언트 구조 - REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임 진다.
이런 REST는 기본 HTTP 프로토콜의 GET/PUT/POST/DELETE를 이용하여 서비스 제공자들에게 요청하는 방식이다. 서비스 제공자는 요청받은 서비스의 리소스를 다양한 형태 (JSON,XML,RSS)로 반환해 준다.
그럼 이 둘의 차이는 무엇일까?
좀 어려운 말로 하면 멱등성(Idempotent), 리소스 결정권이다.
멱등성(Idempotent)
여러번 수행해도 결과가 같은 경우를 의미한다. a = 4 는 명령을 반복적으로 수행해도 그 값이 변하지 않기 때문에 Idempotent 하다고 할 수 있다.
즉 POST 경우에는 리소스를 추가하는 연산이기 때문에 Idempotent 하지 않지만 PUT은 반복 수행해도 Idempotent 하다
리소스 결정권
URL이 서버에 의해 결정되는가, 클라이언트에 의해 결정되는가의 차이이다.
우선 POST는 클라이언트가 실제 저장해야할 리소스의 위치를 모르므로 서버에서 처리하도록 하게 한다.
PUT은 클라이언트가 이미 변경 대상의 리소스의 위치를 알고 있어서, 특정 업뎅이트 대상 리소스를 갱신 할 수 있다.
그럼 PUT과 PATCH는...?
Put - Data에서 하나의 필드만 업데이트 하더라도 항상 모든 필드값을 가져와서 모든 필드를 항상 새로운 값으로 교체
Patch - Data에서 하나의 필드값을 업데이트 시킬때 해당 필드값만 가져와서 해당 부문만 업데이트 한다.
