다음 글은 <깔끔한 파이썬 탄탄한 백엔드> 책을 정리한 내용입니다
-
프론트엔드 시스템과 백엔드 시스템은 http protocol을 기반으로 통신함
-
http의 구조 및 백엔드 api 시스템 개발에 필요한 핵심요소
- http 핵심요소
- http 구조
- 자주 사용되는 http 메소드와 status code
HTTP
http: Hypertext Transfer Protocol
웹 상에서 서로다른 서버간에 하이퍼 텍스트 문서(html)을 주고 받을 수 있도록 만들어진 프로토콜(통신규약)
웹 상에서 네트워크를 통해 서버 사이에 통신할 때 어떠한 형식으로 서로 통신하자고 규정해놓은 통신형식/구조
HTTP 통신 방식
(1) HTTP 의 request/response 방식
-
http는 기본적으로 요청과 응답 형식으로 되어있음
-
백엔드 api 시스템의 엔드포인트 구현도 기본적으로는 http요청을 인풋으로 받아서 http 응답을 아웃풋으로 리턴하는 구조로 구현함
@app.route("\ping", methods=['GET']) def ping(): return "pong"ping end-point의 경우에도, http요청과 응답이 오고가는 구조임
이 경우, http 요청은 '\ping' 주소에 get요청을 보내고
http응답은 200상태 코드와 함께 'pong'이라는 텍스트를 보내는 것임
flask가 http부분을 자동으로 처리해줌
(2) stateless
-
Stateless: 상태가 없다
-
클라이언트와 서버는 http 통신을 여러번 주고받는 것이 일반적인데, http 프로토콜에서는 동일한 클라이언트와 서버가 주고받은 http 통신이라도 서로 연결되어있지 않음 -> 각각의 http통신은 독립적이며 그전에 처리된 http통신에 대해 전혀 알지 못함
-
장점: 서버 디자인이 간단, 효과적임(http 통신들의 상태를 서버에 저장하지 않아도 되므로)
-
단점: http요청을 보낼 때는 해당 요청을 처리하기 위해 필요한 모든 데이터를 매번 포함시켜서(로그인등의 데이터) 요청을 보내야한다
-> 이를 해결하기 위해 쿠키, 세션등을 사용
-
쿠키: 웹 브라우저가 웹사이트에서 보내온 정보를 저장할 수 있도록 하는 조그만 파일. http는 stateless이므로 클라이언트에서 http요청을 보낼 때, 필요한 모든 정보를 포함해서 보내야함. 그러므로 클라이언트가 필요한 정보를 포함해서 보낼 수 있으려면 클라이언트가 정보를 저장할 수 있는 매커니즘이 필요
세션: 쿠키와 마찬가지로 http 통신상에서 필요한 데이터를 저장할 수 있게 하는 메커니즘. 쿠키는 웹브라우저(클라이언트 측)에서 데이터를 저장하는 반면, 세션은 웹서버에서 데이터를 저장
HTTP요청 구조
(1) http 요청
#1. start line
POST /payment-sync HTTP/1.1
#2. headers
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length:83
Content-Type:application/json
Host: intropython.com
User_Agent: HTTPie/0.9.3
#body
{
'imp_uid':'imp_1234567890'
'merchant_uid':'order_id_8231234'
'status':'paid'
}
-
start line
http 요청의 시작줄
search 엔드포인트에 get http 요청을 보냄
GET /search HTTP/1.1-
http method
해당 http요청이 의도하는 액션을 정의함(get, post, put, delete, options)
예. 서버로부터 어떤 데이터를 받고자한다면 get요청을 보냄
서버에 새로운 데이터를 저장하고자 한다면 post요청을 보냄
-
Request target
해당 http요청이 전송되는 목표 주소
pind endpoint에 보내는 http요청의 경우 request target은 '\ping'이 됨
-
HTTP version
해당 요청의 http버전
버전을 명시하는 이유?
http버전에 따라 http요청 메세지의 구조나 데이터가 조금씩 다를 수 있어서
-
-
헤더
http요청 그 자체에 대한 정보
파이썬의 딕셔너리 형태
예. HOST: google.com (구글에 보내는 http요청의 host 헤더)
자주 사용되는 헤더 정보
- Host
- 요청이 전송되는 target 호스트의 url주소를 알려줌
- User-Agent
- 요청을 보내는 클라이언트에 대한 정보 (예. 웹 브라우저에 대한 정보)
- Accept
- 해당 요청이 받을 수 있는 응답 body 데이터 타입을 알려줌
- MIME type
- Connection
- 해당 요청이 끝난 후 클라이언트와 서버가 계속해서 네트워크연결을 유지할것인지 끊을 것인지를 알려줌
- http 통신에서 서버간에 네트워크 연결하는 과정이 다른 작업에 비해 시간이 걸리는 부분이므로 http요청 때마다 네트워크 연결을 새로 만들지 않고 http요청이 계속되는 한 처음 만든 연결을 재사용 하는 것이 선호됨
- Connection: keep-alive -> 앞으로도 계속 http 요청을 보낼 것이므로 네트워크 연결을 유지함
- Connection: close -> 더이상 요청을 안보낼것이므로 네트워크 연결을 닫아도 된다
- Content-Type
- http 요청이 보내는 메시지 body타입을 알려줌
- MIME type
- 예. http요청이 json데이터를 전송하면 content-type: application/json
- Content-length
- http 요청이 보내는 메시지 body의 총 사이즈를 알려줌
- Host
-
body
http 요청 메시지에서 body부분은 요청이 전송하는 데이터를 담고 있는 부분
(2) http 응답
- status line
- http응답 메세지의 상태를 요약하여 알려줌
- Status code 200: 요청이 정상 처리됨
- 헤더
- User-Agent대신에 Server 헤더가 사용됨
- body
자주 사용되는 http method
-
GET
어떠한 데이터를 서버로 부터 요청할 때
-
post
데이터를 생성하거나 수정, 삭제 요청을 할 때
-
options
특정 엔드포인트에서 허용하는 메소드들이 무엇이 있는 지 알고자 하는 요청에서 사용
-
put
Post 메소드와 비슷 -> 그냥 post 써라
-
delete
Post 써라
api 엔드포인트 아키텍처 패턴
(1) REST 방식
RESTful API: api에서 전송하는 리소스를 url로 표현하고 해당 리소스에 행하고자 하는 의도를 http 메소드로 정의하는 방식
각 엔드포인트는 처리하는 리소스를 표현하는 고유의 url 주소를 가지고 있으며, 해당 리소스에 행할 수 있는 행위를 표현하는 http 메소드를 처리가능
예. 사용자 정보를 리턴하는 '\users'라는 엔드포인트에서 사용자 정보를 받아오는 http 요청은 다음과 같다
HTTP GET /users
GET /users새로운 사용자를 생성하는 엔드포인트는 url을 '\ users'로 정하고
POST/ user
{
'name':'송은우'
'email':'singasong@naver.com'
}-
장점
- 자기 설명력: 엔드포인트의 구조만 보더라도 해당 엔드포인트가 제공하는 리소스와 기능을 파악할 수 있음
-
문제점:
- api의 구조가 특정 클라이언트에 맞춰져서 다른 클라이언트에서 사용하기에 적합하지 않게 됨
(2) GraphQL 방식
REST 방식과 다르게 엔드포인트가 하나임
엔드포인트에 클라이언트가 필요한 것을 정의해서 요청함
서버가 정의한 틀에서 클라이언트가 요청하는 것이 아니라 클라이언트가 필요한 것을 서버에 요청함
예. 아이디가 1인 사용자의 정보와 그의 친구들 이름 정보를 api로 부터 받아와야함
GET /users/1
GET /users/1/friends
#이 두번의 요청을 한번의 http 요청으로 줄이기 위해
GET /users/1?include=friends.namegraphQL 사용시
POST /graphql
#사용자의 이름과 나이가 알고싶고,
#사용자 친구의 이름과 이메일이 알고싶을 때
{
user(id:1){
name
age
friends{
name
email
}
}
}