학업을 수행하던 때도 포기하던 네트워크를 다시 여기서 만나게 됐다. 너무나도 거부감이 들었던 유닛이지만 어차피 내가 해나가야 될 부분이기 때문에 그 부분을 감수하고 유닛을 학습했다. 여전히 아직 개념을 제대로 파악하지도 못했고 실습 또한 많이 해보지 않아 나에게는 어렵지만 유닛에서 얻은 개념과 느낀 점들을 풀어보겠다.
잦은 데이터 업데이트가 필요한 경우 리소스가 존재하는 곳(서버)과 리소스를 사용하는 앱(클라이언트)을 분리시키는 것이 유리하다. 이와 같이 분리시킨 것이 클라이언트-서버 아키텍처이다.
클라이언트와 서버는 요청과 응답을 주고 받는 관계이다. 클라이언트가 요청을 하면 서버는 응답을 한다. 요청이 선행되어야하며 요청을 한 번하면 한 번의 응답이 온다.
보통 서버는 리소스를 전달해 줄 뿐이다. 리소스를 저장하는 공간은 데이터 베이스이다. 클라이언트-서버 아키텍처에서 베이터 베이스가 추가된 형태를 3 Tier Architecture라 한다.
프로토콜(Protocol) : 클라이언트와 서버가 통신할 수 있도록 하는 통신 규약이다.
웹 애플리케이션 프로토콜 : HTTP -> 웹에서는 클라이언트와 서버가 HTTP라는 프로토콜을 통해 통신하며, 서로 주고받는 메시지를 HTTP 메시지라고 한다.
API (Application Programming Interface)
HTTP 메소드
GET
POST
PUT
, PATCH
DELETE
HEAD
, OPTIONS
등네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.
scheme
, hosts
, url-path
로 URL을 구분할 수 있다.
https://www.naver.com/
localhost
, 127.0.0.1
: 현재 사용중인 로컬 PC0.0.0.0
, 255.255.255.255
: broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다. 서버에서 접근가능 IP주소를 broadcast address로 지정하면, 모든 기기에서 서버에 접근할 수 있다.22 : SSH
, 80 : HTTP
, 443 : HTTPS
브라우저의 검색 창에 도메인 이름을 입력해 해당 사이트로 이동하기 위해서는, 해당 도메인 이름과 매칭된 IP주소를 확인하는 작업이 반드시 필요하다. 네트워크에는 이를 위한 서버가 별도로 존재하는데 이것이 DNS다.
호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터 베이스 시스템이다.
<form>
태그를 이용한 페이지 전환과 요청에 따른 응답 방식이었다. new XMLHttpRequest()
를 통해 이용할 수 있지만, 이를 편하게 하기 위해 fetch API
가 등장했다. 이는 얼마전에 우리가 실습했던 API다.서버에서 웹 페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링 했기 때문에, SSR이라 한다.
웹 페이지 내용에 데이터 베이스의 데이터가 필요한 경우, 서버는 데이터 베이스의 데이터를 불러온 다음 웹페이지를 완전히 렌더링된 페이지로 변환 후에 브라우저에 응답으로 보낸다.
사용경우
데이터베이스에 저장된 데이터가 필요한 경우 데이터를 가져와 웹페이지를 렌더링 해야하는데 이를 위해 API를 사용한다.
CSR에서는 SSR과 다르게 서버가 웹페이지를 다시 보내지 않으며, 브라우저는 요청한 경로에 따라 페이지를 다시 렌더링한다. 이 때 보이는 웹 페이지 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한다.
사용 경우
HTML과 같은 문서를 전송하기 위한 Application Layer(응용계층 - OSI 7계층에서) 프로토콜이다.
웹 브라우저와 웹 서버의 소통을 위해 디자인 되어 클라이언트가 HTTP Messages 양식에 맞춰 용청을 보내면, 서버도 양식에 맞춰 응답한다.
HTTP의 특징
HTTP Messages는 클라이언트-서버 사이에서 데이터가 교환되는 방식이며, 요청과 응답 두 가지가 존재한다.
HTTP 요청 메소드(MDN) 와 HTTP 메시지(MDN)의 MDN 문서다. 이것을 보는 것이 제일 좋을 것이다.
웹(http)의 장점을 최대한 활용할 수 있는 아키텍처로 소개됐다.
REST API === RESTful한 HTTP API
HTTP API를
endpoint
두 가지 링크를 참조하는 것이 좋다.
REST API 설계시 중요한 점
URI는 정보의 자원을 표현한다.
자원에 대한 상태정의는 HTTP Method(GET, POST, PUT, DELETE ...)로 표현된다.
실습은 페어 프로그래밍으로 진행됐지만, 코딩을 하는 것보다는 툴을 이용하는 실습으로 이루어졌다. url을 통한 공공데이터의 정보 조회, POSTMAN을 이용한 조회 작업과 CREATE작업을 하는 실습을 했다. 이 유닛을 학습하면서 잘 이해되지 않았던 HTTP Messages의 구조를 POSTMAN을 이용해서 눈으로 직접 확인하니 메시지 구조를 파악하기 쉬웠던 것 같다. 아직은 코딩을 하며 제대로 접목시키지는 못하고 사용방법만을 익혔는데, 이를 잘 생각하고 다음에 접목시킬 일이 있으면 제대로 적용시킬 수 있어야 할 것이다. 확실히 개념만 익히기보다는 실습을 통해서 얻는 것이 좋은 방법 같다. 이번 유닛은 내용이 꽤 어려워서 복습도 중요할 것이다. 힘내자 !