백엔드에서는 클라이언트(쉽게 설명하자면 프론트엔드)에서 request하는 데이터에 대한 적절한 response를 응답해주어야 한다.
Udemy에 있는 'Fundamentals of Backend Engineering'에 대한 강의를 듣고, 나름의 정리를 해보았다.
Request Response 모델 정의
- Client는 Request를 보낸다.
- Server는 Request에 대한 분석을 한다.
- Server는 Request를 처리한다.
- Client는 Server가 분석한 Response를 분석하고 consume한다.
-> 결국 API가 필요한 것이다. 프론트엔드가 필요한 데이터 응답을 만들어주기 위해 프론트엔드에서 요청하는 데이터 response를 API 형태로 내려주는 것이 백엔드의 역할이라고 업무를 하면서 생각하였다.
request response 모델이 쓰이는 곳은?
- Web, HTTP, DNS, SSH
- RPC(Remote Procedure Call)
- APIs(REST,GraphQL,SOAP)
- SQL 그리고 Database Protocols
'Request 구조는 client와 서버 둘다 정의된다'라는 말이 나왔는데, 좀 더 정확히 파악하기 위해 자료를 찾아보았다.
HTTP 구조 자체가 HyperText를 교환하기 위한 통신 구조이다.
※HyperText는 일반 텍스트와 달리 특정 부분을 클릭하면(예를 들면 버튼이나 링크 등) 관련된 다른 문서나 리소스로 이동한다는 점에서 차이가 있다.
HTTP 구조
- StartLine
- HTTP Method : @GET(조회), @POST(데이터 삽입), @PUT(데이터 수정), @DELETE(데이터 삭제)와 같은 요청의 의도가 담겨져 있다.
- Request Target : HTTP Request가 전송되는 목적지 주소
- HTTP Version : version에 따라 Request 메시지나 데이터 구조가 다를 수 있어 version을 명시함. 주로 HTTP/1.1이 널리 쓰이는 버전이다.
- Headers : 요청에 대한 부가적인 정보(인증,콘텐츠 유형,사용자 에이전트 등)을 담고 있다.
- Body : 클라이언트가 서버로 전송하는 데이터가 담길 수 있다. 주로 @POST나 @PUT이 사용된다.
분명 이전에도 배웠던 개념인데, 업무를 시작하고나서 보니 그 의미가 더 잘 와닿는 것 같다!
※ curl을 이용한 인터넷 데이터 전송을 간단하게 해보자.
-> curl은 인터넷 데이터 전송을 위한 도구이다.
1) Mac 터미널에 아래와 같이 입력하였다. 테스트는 google
curl -v --trace out.txt http://google.com2) 아래와 같이 <html> 형태의 무언가 답이 나왔다. href 링크가 google.com으로 잘 걸어져있다.
Warning: --trace overrides an earlier trace/verbose option
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.301은 처음 보는 HTTP 상태 코드였는데, 리디렉션을 나타낸다고 한다. 주로 301 Moved Permanetly가 뜨는 것 같은데, 클라이언트가 요청한 리소스가 영구적으로 다른 위치로 이동되었다는 뜻이다.
위의 코드는 Permanetly 키워드가 없으므로 단순히 google.com이라는 하이퍼링크 주소로 옮겨졌다는 의미인 것 같다.
3) 데이터를 받아서 터미널에 뿌려주는 'cat'명령어를 이용해 앞선 파일 이름인 out.txt에서 google.com에서 받아온 데이터를 터미널에 보여준다.
cat out.txtConnected to google.com ~ 이라는 구글 홈페이지 연결 시작과 함께
=> send : request
<= Recv : response 화살표 방향에 따라 데이터를 주고받는 값들이 터미널에 출력된다.
=> Send header, 74 bytes (0x4a)
0000: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HTTP/1.1..
0010: 48 6f 73 74 3a 20 67 6f 6f 67 6c 65 2e 63 6f 6d Host: google.com
0020: 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 75 ..User-Agent: cu
0030: 72 6c 2f 37 2e 38 35 2e 30 0d 0a 41 63 63 65 70 rl/7.85.0..Accep
0040: 74 3a 20 2a 2f 2a 0d 0a 0d 0a t: */*....
== Info: Mark bundle as not supporting multiuse
<= Recv header, 32 bytes (0x20)
0000: 48 54 54 50 2f 31 2e 31 20 33 30 31 20 4d 6f 76 HTTP/1.1 301 Mov
0010: 65 64 20 50 65 72 6d 61 6e 65 6e 74 6c 79 0d 0a ed Permanently..
<= Recv header, 34 bytes (0x22)
0000: 4c 6f 63 61 74 69 6f 6e 3a 20 68 74 74 70 3a 2f Location: http:/
0010: 2f 77 77 77 2e 67 6f 6f 67 6c 65 2e 63 6f 6d 2f /www.google.com/
0020: 0d 0a이런 느낌으로, 데이터를 request하고 response 하는 것을 터미널에서 볼 수 있다. 각 줄의 의미는 잘 모르겠다..ㅎㅎ
일단 curl을 이용해 데이터를 어떻게 request하고 response할 수 있는지를 보기 위한 용도이므로, 연습해보기는 좋은 것 같다.
백엔드,프론트엔드 모두 request와 response의 구조에 대해 둘다 잘 파악하고 있어야겠다는 생각이 들었다.
백엔드 개발자로서도 프론트엔드에게 request에 맞는 올바른 response를 내려주기 위해 끊임없는 고민을 해야겠다. :)
'Backend' 카테고리의 다른 글
| 모니터링 시스템 구축을 위한 리서치 (0) | 2023.11.08 |
|---|---|
| 블록체인 이벤트 수신 시 로컬에서 이벤트 수신 vs kubernates의 pods로 이벤트 수신 차이점 (0) | 2023.07.18 |
| 백엔드 > 프론트엔드 데이터 전달과정(API,블록체인) (0) | 2023.03.14 |
| '어디서' 데이터를 가져오느냐 / '어떤' 데이터를 가져오느냐 -> API와 Contract 그 경계 (0) | 2023.03.09 |