1. 서버와 클라이언트
클라이언트는 손놈, 서버는 가게 주인이라고 생각하면 이해하기 편하다.
손놈이 뭔가를 요청한다. (GET) 서버는 그 요청을 보고 내용을 던져준다.
손놈이 뭔가를 준다. (POST) 서버는 그걸 받고 응답한다.
손놈이 뭔가 지워달라고 한다. (DELETE) 서버는 지운다.
손놈이 뭔가 고쳐달라고 한다. (Patch, Put) 서버는 무언가를 고쳐준다.
우리는 각종 매체를 사용해서 클라이언트 역할을 한다. 어플로 어느 웹사이트를 쓴다거나, 쇼핑을 하고, 사진을 보고 채팅을 한다.
서버는 우리의 요청에 따라 응답한다. 그리고 우리 요청이 얼탱이가 없으면 에러를 뱉음.
API?
서버와 클라이언트가 서로 통신하기 위해서는 일종의 약속(규약, 규칙)이 필요하다.
우리가 보통 API라고 부르는 것은 HTTP라는 통신 규칙으로 소통하는 API다.
Application Programming Interface의 약자다. 서버는 클라이언트에게 리소스를 활용할 수 있도록 인터페이스를 제공한다.
일종의 메뉴판 역할을 하는 것이다. 만약 클라이언트가 이 API를 통해 무언가를 요청했는데, 그게 메뉴판에 없으면 400에러를 보낸다.
상황에 따라 500이든 뭐든 에러가 튀어나감.
이때 URL, URI를 이용하고, API를 통해 클라이언트는 Get, Post, Put, Delete같은 요청을 보낸다. 이게 CRUD다.
java, spring을 이용한 CRUD
자바스크립트를 이용한 CRUD
즉 API는 어떤 프로그램이 제공하는 기능을 사용할 수 있게 만든 매개체라고 볼 수 있다.
이런 HTTP API를 잘 이용하게 만든 원칙이 바로 REST API고 현재 백엔드 엔지니어에게 필수적인 지식이 됐다.
API는 웹에서만 국한되지 않는다. Java의 Util이나 Io같은 애들도 죄다 API라 볼 수 있음.
그러므로 우리가 말하는 CRUD, RestAPI는 HTTP API를 기반으로 생각해야 한다.
URL, URI?
URL은 Uniform Resource Locator의 줄임말이다. 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.
상기 그림처럼 schema, hosts, url-path를 포함한다.
스키마는 통신 방식을 말한다.
hosts는 말 그대로 도메인, ip를 사용한 서버의 메인 path를 말한다.
url-path는 메인페이지 디렉토리를 포함한 하위 디렉토리나 파일명 등을 모두 포괄한다.
여기서 query나 북마크 등이 추가되면 URI가 된다.
URI는 Uniform Resource Identifier의 줄임말이다. URI는 URL을 포함하는 개념이다.
query는 url-path에 붙는 추가적인 정보다. 서버측에 보내는 질문과도 같다.
이 URI를 잘 만들어야 Restful한 API를 설계했다고 할 수 있다.
IP, Port
IP는 흔히들 알듯, 네트워크의 주소라 할 수 있다.
127.0.0.1:8080
이건 내 컴퓨터의 8080포트를 의미한다. 127.0.0.1은 보통 자기 자신을 의미함.
naver도 이런 ip를 가지고 있다. 이게 있어야 네트워크, 인터넷에서 접근이 가능하다.
IP는 Internet Protocol의 줄임말이다. 인터넷에서 사용하는 주소체계를 의미하고 IPv4, IPv6라는 종류가 있다. IPv4로는 이미 주소가 가득 찬 수준이고 (할당할 수 있는 주소가 부족), IPv6를 사용하면 2128개의 주소를 표현할 수 있다.
127.0.0.1은 localhost로도 표현할 수 있다. 이를 도메인, DNS라고 한다. 우리가 주로 사용하는 모든 사이트들은 도메인을 가지고 있다. 아무래도 IP주소만으로 다른 서버에 접속하기엔 문제가 있다. 너무 명확하지가 않음.
모든 도메인은 IP를 가지고 있다. nslookup 명령어를 사용하면 ip주소를 알아낼 수 있음.
DNS는 Domain Name System의 줄임말이다.
포트는 해당 ip에서 이용할 수 있는 통로(채널)을 의미한다. localhost:8080이라 하면 127.0.0.1 ip에 8080이란 채널을 사용하겠다 라는 의미가 된다. 포트번호는 0 ~ 65,535까지 사용할 수 있으며, 일반적으로 IDE에서 서버를 열땐 8080으로 열린다.
0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.
22 : SSH 포트
80 : HTTP
443 : HTTPS
등이 있다.
스프링으로 8080포트를 이용해 톰캣 서버를 구동한 모습이다.
2. HTTP
HTTP는 HyperText Transfer Protocol의 줄임말이다.
어릴때 HyperText의 파와 어쩌구저쩌구 진짜 엄청 들었는데, 그게 그렇게 대단한건가 싶기도 했다. 후... 결국 그 HyperText를 기반으로 여기저기 다 퍼져나갔으니 대단한건 맞는듯?
하여튼 HTTP는 Application Layer 프로토콜로 웹 브라우저와 웹 서버의 소통을 위해 디자인 됐다. 전통적인 클라이언트 - 서버 모델에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면 서버도 HTTP messages 양식에 맞춰 응답한다. HTTP는 특정 상태를 유지하지 않는 무상태성을 가지고 있다.
HTTP messages
HTTP는 Request, Response / 요청, 응답 두가지 유형이 있다. 우리가 스프링에서 그렇게 공부했던 HttpServletRequest, HttpServletRespose도 다 여기서 튀어나온거임.
보통 우리가 직접 지정하지 않는 이상 기본적인 것들은 자동으로 만들어진다.
클라이언트에서 Post 요청을 했다. (start-line)
host는 localhost, 127.0.0.1 즉 본인 컴퓨터네 (HTTP-Header)
컨텐트 타입은 text/html이거 charset은 iso로 맞춰져있다. 아마 한글은 외계어나올듯?
컨텐츠의 길이, 타입, 날짜 등을 다 볼 수 있다. 보통 저걸 일일히 개발자가 지정하진 않는다.
물론 하려면 할 수 있지만 굳이 할 필요는 없음. 필요할 때만 하면 된다.
컨텐트 타입을 뭐 강제로 Application/JSON으로 한다던가 할 때가 있을까 싶다.
언어 가중치는 그래도 할 일이 있을 순 있겠다.
Start-line
요청이나 응답의 상태를 나타낸다. 항상 첫 번째 줄에 위치한다. 응답에서는 Status-line이라고 부른다.
상기 이미지에서 요청에선 Post를 요청했음을 알 수 있고 그 응답으로 403 에러코드를 보내줬다.
HTTP headers
Http body에 있는 모든 것들을 간략하게 설명해주는 부분이다.
언어 가중치나, 컨텐츠의 타입 (text/html, application/json 등)이나 길이 등등 들어가 있다.
이 헤더가 일종의 메타데이터 역할을 해준다. 여기서 utf-8로 지정안해두면 한글이 깨질 수도 있음.
브라우저는 이 헤더를 보고 대충 그 내용을 파악한다.
종류는 위와 같다.
General headers는 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와 관련이 그닥 없다.
Request headers는 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미한다.
Representation headers는 body에 담긴 리소스의 정보를 포함하는 헤더다
HTTP body
요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다. 요청과 응답의 유형에 따라 선택적으로 사용하며, 꼭 모든 요청 혹은 응답에 body가 있을 필요는 없다.
https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
HTTP 메시지에 대한 자세한 내용이 담긴 페이지다. 공부할 때 참고하자.
Stateless 무상태성
HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP는 클라이언트나 서버의 상태를 확인하지 않는다. 클라이언트가 요청을 보냈는데 서버가 박살나 있더라도 HTTP는 신경쓰지 않고 요청 메시지를 보내고 아마 오는게 없으니까 에러코드를 브라우저에 띄울거다. 클라이언트의 모든 상태를 HTTP 통신이 추적하지 않고 마찬가지고 서버의 모든 상태를 HTTP 통신이 추적하지 않는다. 그렇기에 HTTP는 상태를 저장해두지 않으며, 필요에 따라 쿠키 혹은 세션을 통해 현재 상태가 이런 상황이라는 것을 일정부분 확인할 수 있다.
이를테면 쇼핑몰에서 물건을 장바구니에 담게되면, 쿠키를 통해 정보를 저장할거고 로그인 상태라른 것을 확인하기 위해 세션을 부여하고 이용할 것이다.
쿠키는 보통 클라이언트에 저장한다. 보안에 취약할 수 있으나 간편하고 빠르다.
세션은 보통 정보를 서버에서 가지고 있고 그 ID를 클라이언트에게 발급해준다. 서버기 때문에 보안에 조금 더 강하긴 하다.
쿠키의 경우 잘못다루게 되면, ID나 PW를 유추할 수 있는 상황을 제공할 수 있다. 그렇기에 그런 취약점을 보완하기 위하여 세션이 만들어졌고, 세션에서도 UUID등을 통해서 ID나 PW, 혹은 UserID (DB상의 Primary Key)를 유추할 수 없게 보안에 신경써야 한다.
HTTP Request
Http를 통해 클라이언트가 서버에 무언가를 요청하는 것을 HTTP Request라고 한다.
이를테면 Get요청을 서버에 한다손 치자
Get요청으로 "/add"가 들어왔다. 그리고 우리는 addForm으로 html템플릿을 보내줬다. 그러면 클라이언트는 addForm 템플릿으로 이동하게 될거임.
여기서 재미난 구석이 바로 메서드다. Get은 Http Request의 메서드로 사용자가 어떤걸 얻고 싶어서 보낸 요청인거임.
여기서 Post로 메서드를 바꾸고 주소는 그대로 한다면, 그 행위로 Http api의 분리가 가능한거다.
HTTP Response
Request에 날라온 요청들에 서버가 응답을 하는게 바로 이놈이다. 만약 잘못된 응답이 온다면 에러 상태코드를 뱉을 거다. 그 중 가장 유명한게 404 Not Found ㅋㅋ
하여튼 Http header에 상태코드를 넣어주고 개발자가 짜놓은 로직으로 클라이언트에 그 결과를 보내준다. 상기 이미지에서 클라이언트가 Get"/add"를 요청하면 addForm으로 Response를 보내주는게 응답이라 할 수 있겠다.
그리고 Post"/add"를 할 경우엔 클라이언트가 보낸 정보를 토대로 Item이라는 새로운 객체를 만들고 save라는 메서드를 사용해 아이템을 저장하는 로직이 짜여져 있다. 그리고 클라이언트에게 items/itemId라는 주소로 리다이렉트를 시켜준다. 이는 item의 상세페이지다.
3. AJAX
AJAX는 Asynchronous JavaScript And XMLHttpRequest의 약자다.
JavaScript, Dom, Fetch, XMLHttpRequest, HTML등의 다양한 기술을 사용하는 웹 갭라 기법이다.
이 AJAX의 특징으로는 웹페이지의 일정부분만 비동기적으로 받아와 화면에 그려낼 수 있다는 거다.
비동기적이라는 말이 헷갈릴 수 있다. 얘 혼자 따로 작업한다고 보면 편한데, 여기선 그냥 실시간으로 우리의 요청을 처리해준다고 생각하자. 물론 진짜진짜진짜로 엄밀한 접근은 좀 더 길고 예시도 있어야 하니까 꼭 찾아보길 바란다.
하여튼 Ajax를 활용하면 백그라운드 영역에서 서버와 통신하여, 그 결과를 웹페이지의 일부분에만 표시할 수 있다.
AJAX의 장점
- 웹 페이지 전체를 다시 로딩하지 않고도, 일부분만을 갱신할 수 있다.
- 웸 페이지가 로드된 후에 서버로 데이터 요청을 보낼 수 있다.
- 웹 페이지가 로드된 후에 서버로부터 데이터를 받을 수 있다.
- 백그라운드 영역에서 서버로 데이터를 보낼 수 있다.
상기 장점에서 파생되는거지만 일부 데이터만을 주고받기 때문에 데이터의 크기가 작다. 당연하게도 전체 데이터를 다시 불러오는 것보단 훨씬 좋다.
AJAX의 단점
-
뒤로가기 버튼을 따로 설정해줘야 한다. AJAX는 이전 페이지를 기억하고 있지 않기 때문에, History API를 따로 사용하고, 지정해줘야 한다.
-
클라이언트가 서버에 데이터를 요청하는 클라이언트 풀링 방식을 사용하므로, 서버 푸시 방식의 실시간 서비스는 만들기 어렵다.
-
Ajax로는 바이너리 데이터를 보내거나 받을 수 없다. 단순 html 뼈대만 있기 때문임
-
Ajax 스크립트가 포함된 서버가 아닌 다른 서버로 Ajax 요청을 보낼 수가 없다.
나 같은 경우 jQuery를 이용해서 채팅 서비스를 흉내냈었다. 흠.. 정말 쪼금 해본거라 Ajax를 안다고 말하기도 힘듬...
4. SSR, CSR
SSR
SSR은 Server Side Rendering의 줄임말이다.
어떠한 데이터를 서버에서 렌더링한 후에 클라이언트로 보내준다. 서버가 렌더링 하기 때문에 Server Side Rendering이다.
웹 페이지의 내용에 관한 DB의 데이터가 필요한 경우, 서버는 DB의 데이터를 불러온 다음, 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보낸다. 만약 클라이언트가 경로를 이동하면 서버는 이 작업을 계속 수행하게 된다.
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우 이 방식을 선호한다. 단일 파일 용량이 작을 수 밖에 없기 때문에 빠르다.
그러나 클라이언트가 다른 행동을 할 시에 계속 데이터를 렌더링하고 보내줘야 하므로 이는 효율 문제가 발생할 수 있다.
그렇기에 사용자와 상호작용이 적은 경우 활용해야 하겠다.
- 검색엔진(Search Engine Optimization)이 중요한 서비스일 경우
- 첫 화면 렌더링이 빠르게 필요한 경우
- 사용자와 상호작용이 적은 경우
CSR
CSR은 Client Side Rendering을 의미한다. CSR은 말 그대로 클라이언트에서 웹 사이트, 페이지를 렌더링 하는 방식이다.
일반적으로 웹 개발시 이런 방식을 이용한다. 서버가 클라이언트에게 HTML, JavaScript를 보내며, 브라우저가 그에따라 렌더링을 한다면 이게 바로 CSR이다.
- 검색엔진(Search Engine Optimization)이 중요하지 않을 경우.
- 사이트에 풍부한 상호 작용이 있는 경우
- 웹 애플리케이션을 제작하는 경우 (리액트, 뷰)
최근 대세는 이 CSR이고, 네이버 블로그처럼 검색 엔진 최적화에 중점이 없는 사이트라면 모두 이 CSR을 이용하고 있다.
