본문 바로가기

공부/CS 이론 및 활용

[Front-end/Back-end] 클라이언트, 서버, 웹서버, API 그리고 REST API

들어가기 전에(link)
 

1. 프론트앤드 컨텐츠의 종류

1) 정적 컨텐츠
: 클라이언트 요청 시 서버에 미리 저장된 파일(HTML, CSS, JS)을 그대로 응답해서 보여주는 것. 워드 문서 파일을 생각해보자. 내가 누군가에게 파일을 전송한다면 수정하지 않는 한 내용은 항상 동일하지 않은가?
>> 정적 컨텐츠는 모든 클라이언트의 요청에 항상 동일한 결과를 보여준다.
 
2) 동적 컨텐츠
: 누가, 언제, 어디서, 어떻게, 무엇을 요청했는지(사용자의 환경)에 따라 각기 다른 결과를 보여주는 것. 우리가 생각하는 인터넷 페이지는 거의 동적 컨텐츠에 해당한다. 네이버 뉴스창이 "오늘", "내 알고리즘"과 일치하는 뉴스를 상단에 띄워주는 것처럼 사소한 변화들 모두가 모두 동적 컨텐츠이기 때문에 발생한다.
 
3) 웹문서
: 웹 브라우저가 해석할 수 있게 설계된 문서. 인터넷 환경에서 정보값 교환(이동)을 위해 웹 페이지를 생성하기 최적화된 문서이다.

  HTML은 웹문서를 작성하는 언어이고, 작성된 웹문서는 웹 서버에 저장되며, 웹 브라우저가 웹문서를 요청하면 전송되어 웹 브라우저에 의해 웹페이지 형태로 제공한다. 어려우니 아래에 이어서...

 
번외) 웹문서 vs 웹페이지

더보기

웹문서(Web Document)

: HTML, CSS, JavaScript 등으로 구성된 파일을 의미. 서버에 저장된 특정 파일

 

>> 웹문서를 웹 브라우저가 받아와 웹페이지로 사용자가 볼 수 있게 렌더링한다.

 

웹페이지(Web Page)

: 웹문서가 브라우저에 의해 해석되어 사용자가 볼 수 있는 형태로 나타난 것

 

>> 정리하자면, 웹문서는 외부에서 접근할 수 있는 페이지를 만들기 위한 코드 문서,

이것을 웹브라우저가 랜더링해 띄워준 것이 웹페이지

 

+)브라우저가 HTML 웹문서 파일을 가져와 보여준다면, 정적컨텐츠이다.

여기에 JS에 의한 변화가 추가되면 동적컨텐츠로 진화

 

2. 그럼 서버가 뭐에요?

: 웹 문서를 주는 쪽이 서버이고, 반대로 받는 쪽은 클라이언트이다. 이 때, 서버는 그냥 아무때나/아무 문서를 주는 것이 아니라 클라이언트의 요청(request)에 반응해 웹문서를 전달(response)한다.
 

2.1 Client

: 네트워크를 통해 다른 컴퓨터 시스템 원격 서비스(서버)에 접근할 수 있는 응용 프로그램이나 서비스. 아주 좁은 의미로, user가 단말기로 접속하는 웹 브라우저(chrome,  edge 등)
 
1) client 웹 브라우저의 역할은?

  • 서버가 제공하는 서비스를 요청하고(request - Get)
  • 서비스 요청을 위해 필요 인자를 서버가 원하는 방식에 맞게 제공하며(request -  Post)
  • 서버로부터 반환된 응답을 사용자에게 적절한 방식으로 표현하는 것(respose - rendering)

 
2) Request의 종류

  • GET방식: url을 사용하여 서버에서 정보를 가져오는 방식(이 주문대로 가져와줘)

  • POST방식: 사용자로부터 정보를 받아, 서버에 입력하거나 수정하는 방식

 

2.2 HTTP(Hypertext Transfer Protocol)

: 서버와 클라이언트 간 원활한 대화를 위해 만든 네트워크에서 가장 범용적인 송수신 통신 규약(규격 포장지)

  • 모든 웹 브라우저가 서버에 request할 때, 모두 이 규칙을 따른다.
  • User가 URL을 입력하면 브라우저가 HTTP 방식으로 부가적 정보를 담아 Reequest한다

>>> 사용자가 웹 브라우저에 특정 URL을 입력하면, HTTP를 통해 브라우저가 해당 서버에 요청을 보내고, 서버는 응답으로 해당 웹 페이지 데이터를 전송
 

2.2.1 HTTP의 동작

1) 요청(request)
: 사용자가 브라우저에 url을 입력하거나 상호작용(아이디/패스워드 입력)을 한 순간, 브라우저는 이 요청들을 HTTP 방식으로 서버로 요청을 보낸다. request는 다음으로 구성된다.

  • 요청 method: 서버에 요청하는 작업 유형
  • url: 요청받으려는 리소스의 서버 내 경로
  • header: 요청 리소스에 대한 추가 정보
  • body: 주로 POST 요청에 사용되는 서버에 보낼 데이터

2)  응답
: 서버는 클라이언트의 요청을 처리하고, 이에 대한 HTTP 응답을 보낸다. 응답에는 다음 정보가 포함된다.

  • 상태 코드(Status Code): 요청의 처리 결과를 나타내는 숫자 코드(예: 200 OK, 404 Not Found)
  • 헤더(Header): 응답에 대한 추가 정보(예: 콘텐츠 타입, 캐시 제어 등)
  • 본문(Body): 요청된 리소스(HTML, JSON 데이터 등)

 

2.3 서버

: 1) 데이터를 저장하고 처리하거나 (내부), 2) 클라이언트(사용자)로부터 요청을 받아 서비스를 제공(외부)하는 프로그램(소프트웨어)나 소프트웨어가 설치된 컴퓨터(리눅스 등 운영체제가 있는 하드웨어)

  • 다양한 프로토콜로 통신: HTTP, FTP, SMTP 등을 사용
  • 다양한 역할: 제공 서비스의 종류 별로 정해진 port가 있다. 웹 서버(80) / 데이터베이스 서버(mysql:3306) / DNS 서버(1023, 53) / FTP 서버(21) / ssh 서버(22)/ 메일 서버(110,25,143

>> 서버가 다양한 역할을 수행하는 반면, 웹서버는 서버의 한 종류로 클라이언트 요청을 가장 먼저 처리하는 역할을 한다
(서버가 웹서버를 포괄하는 개념)

 

2.3.1 웹서버(Web Server)란?

  1. 하드웨어 측면
    : 아래 소프트웨어가 실제로 동작하는 서버(컴퓨터). 인터넷에 연결되어 있어 IP 주소를 가지고 있으며, 이를 통해 클라이언트와 연결된다.
  2. 소프트웨어 측면
    1. 클라이언트(주로 웹 브라우저)로부터 HTTP 요청을 받아 정적 컨텐츠를 제공하거나
      • HTTP request IN, HTTP response out
      • 주요 웹서버로는 PHP 기반의 Apache가 있다
    2. 동적 요청을 웹 애플리케이션 서버(WAS)로 전달

1) 웹서버의 특징

  • HTTP 기반 통신: 클라이언트와 HTTP/HTTPS 프로토콜을 사용하여 통신한다.
  • 정적 콘텐츠 제공 역할(외부): 정적 파일을 클라이언트에 직접 전달한다.
  • 리버스 프록시 역할(내부): 클라이언트 요청을 애플리케이션 서버로 전달하고, 결과를 받아 응답한다.

2) 서버 내에 웹서버가 필요한 이유는?

  1. 정적 콘텐츠 처리: HTML, CSS, 이미지 파일을 빠르게 처리
  2. 부하 분산: 클라이언트 요청을 애플리케이션 서버로 분배하여 부하를 감소
  3. 보안: 클라이언트가 애플리케이션 서버에 직접 접근하지 못하도록 보호
  4. 리버스 프록시 역: 여러 서버로 요청을 전달하고 응답을 조합
3) 웹서버가 서버 안에서 동작하는 방식 요청 처리 흐름
  1. 클라이언트 요청: 사용자가 브라우저에서 URL을 입력하여 HTTP 요청을 보낸다.
  2. 웹서버:
    • 요청이 정적 콘텐츠(HTML, CSS, JS 등)라면 바로 응답
    • 요청이 동적 콘텐츠(API, 데이터베이스 조회 등)라면 애플리케이션 서버로 전달
  3. 애플리케이션 서버:
    • 비즈니스 로직을 처리하고 결과를 반환한다.
  4. 웹서버: 애플리케이션 서버로부터 받은 결과를 클라이언트에게 응답으로 전송한다.

 
번외) Q. 최고의 축구 팀을 만드는 요청을 보내보자

더보기

A. 

  1. 웹 브라우저가 기본 URL을 사용하여 서버에 HTTP GET request을 생성하고(/best),
    1. 그리고 팀 및 플레이어의 수를 URL인자로 인코딩하거나(예. /best?team=my_team_name&show=11)
    2. 또는 URL패턴 (예. /best/my_team_name/11/) 으로 인코딩.
      • GET request를 사용하는 이유는 본 요청이 데이터를 꺼내오는 데에만 사용되기(데이터가 수정 되지 않음)이기 때문
  2. 웹 서버는 이 요청이 "동적 요청"임을 감지하고 처리를 위해 웹 어플리케이션(WAS)에 전달
    • 웹서버가 기존 정의된 패턴 매칭 방법을 통해 다양한 URL 처리 방법을 결정함
  3. 웹 애플리케션이 URL을 기반으로
    1. 요청의 목적("최고의 팀 목록"을 얻는 것)을 확인하고(/best/)
    2. URL에서 필요한 팀 이름과 플레이어의 숫자를 찾아냄
  4. 웹 어플리케이션이 데이터베이스에 접근해 필요한 정보를 가져옴
    • 추가 "내부의" 인자들을 사용하여 어떤 플레이어가 "최고"인지 정의하고,
    • 클라이언트측 쿠키를 통해 로그인한 코치의 신분 확인 가능)
  5. 웹 어플리케이션이 데이터(from 데이터베이스)를 넣은 HTML 동적생성
  6. 웹 어플리케이션이 웹 서버를 경유하여, HTML과 HTTP 상태코드 200 ("success")를 브라우저에 함께 반환
    • 도중에 HTML 반환을 막혔다면, 웹 어플리케이션은 200이 아니라 다른 코드를 반환(예를 들어, "404"는 팀이 존재 하지 않는다는 코드)
  7. 웹 브라우저가 반환한 HTML을 처리하고 참조하는 다른 CSS파일이나 Javascript 파일을 얻기위해 별도의 요청을 보낸다
  8. 웹 사이트는 파일 시스템에 있는 정적 파일을 로드하고 즉시 브라우저에 반환합니다(올바른 파일 처리는 설정 방법과 URL패턴 매칭을 기반으로 함)

 
4) 프론트앤드와 백앤드?

  1. Back-end : 사용자의 요청을 받아, 저장되어 있는 정보를 각 사용자에게 적합한 페이지를 전송하기까지의 과정
    1. 웹 서버(Apache, IIS, nginx, GWS, 등): 사용자의 요청에 맞게 데이터(HTML, Image 등)를 전송해주는 프로그램
    2. 스크립트 엔진(php, jsp, asp): 웹 서버에서 사용자의 요청을 분석해주는 프로그램
    3. 데이터 베이스(MsSQL, Oracle, MySQL, PostgreSQL, MongoDB 등): - 사용자의 정보를 저장하는 저장소
    4. 웹 프레임 워크(Django, Ruby on Rails, ASP.NET 등): 웹 개발을 편리하게 만들어 주는 도구
  2. Frond-end: HTML, CSS, Java Script처럼, 주로 클라이언트 측에서 실행되어 사용자가 웹 페이지와 상호작용하는데 사용되는 코드를 다룸(최종 output을 뿌려주는 과정)

 

3. API (Application Programming Interface)

: HTTP 방식이 아닌 또 다른 소통방식의 일종. API의 기능은 요청과 연결, 2가지로 나눌 수 있는 것 같다.

 
  첫 번째는 원활한 프로그램 간 통신을 위한 통신 형식 제공. 클라이언트나 프로그램이 접근하고자 하는 상대 프로그램 규칙이 복잡한 경우, API라는 규칙을 사용하면 원활한 통신이 가능하다. API로 프로그램에서 사용하려는 기능들을 미리 정리하고 규칙을 잘 세워두면 클라이언트는 접근할 프로그램을 몰라도 API를 통해 손쉽게 통신할 수 있게 되기 때문이다.

이를 위해 프로그램은 해당 서버의 API 규칙에 맞춰 request를 보내야 한다.
API 요청의 종류는 POST:올려줘 GET: 불러와 PUT/PATCH: 수정해 DELETE: 지워줘

 
  두 번째는 프로그램과 프로그램을 연결시켜주는 매개체. 핸드폰 어플을 새로 깔았을 때 다른 프로그램 접근 권한이 필요한 것처럼(통신할거야!! 권한 내놔!!), 프로그램들 끼리도 많은 통신을 하며 이는 보통 API를 이용해서 이루어진다.
 
  비슷한 맥락으로 보안 상 외부에서 누구나 사용할 수 없는 서버 프로그램의 제한된 기능들을 로컬에서 간접적으로 제공하고 싶을 때, 마찬가지로 API가 사용된다. 한 기기 내 프로그램과 프로그램이 소통할 때도, 프로그램과 서버가 소통할 때도 API가 필요한 것이다.
 
  프로그램들이 한 기기 내에서 연결된 것과, 네트워크 상에서 연결된 것은 거리의 차이가 있을 뿐 서로 다른 프로그램이라는 건 같기 때문에 서로 호환되려면 접근 허가가 필요하다.

 

 정리하자면 이론적인  API(Application Programing Interface)는 서비스의 요청과 응답에 대한 규칙을 의미하고, 일반적으로는 요청과 응답을 처리하는 서비스(기능)를 의미한다.

 
** API는 어플리케이션, WAS는 웹 통신을 위한 서버라고 한다 link
 
번외) 전반적 흐름 예시

더보기

클라이언트와 서버 간 상호작용을 예로 들어보자.

  1. API가 API어로 데이터 좀 보내달라는 편지를 API 서버 수신인으로 보낸다
    (왜냐면 다른 서버 파츠들는 API어를 알아들을 수 없으니까).
  2. API서버는 왜 이 편지를 나에게 보내? 라고 생각하지 않고,
    이 편지는 데이터를 원하는 편지이니 DB에게 전달되어야 하는 편지이며
  3. DB는 API어를 이해하지 못하니 번역해주어야지(번역 완)
  4. DB야 받아라!

>> API서버가 기존에 지정된 경로-예약어를 이용해 request를 처리할 서버를 정리해주기 때문에 분업 향상, 처리속도 증가

 

1) API 문서

: API의 함수, 매개변수, 반환값 및 사용 예제에 대한 정보를 제공하는 일련의 문서. API를 사용해 애플리케이션을 구축하거나 다른 시스템과 통합하려는 개발자를 위한 참조 가이드 역할

 

  카카오 로그인 API 문서를 보면 어디(url)에 무엇을(Parameter)을 보내면 무슨 응답(Response)을 줄지가 전부 약속되어 있는 것을 확인할 수 있다. 이 경우는 API의 첫번째 특성을 보여준다. 또한 카카오 API는 openAPI인데(로그인 자동연동)

2) open API 

: 네이버, 카카오 등 sdk에서 제공하는 API로 모두에게 공개되어 있는 API (sdk: Software Development Kit ,소프트웨어 개발 도구) 다른 회사와 협업할 때, 우리 회사에 없는 data 활용할 때 (ex - 날씨, 구글맵, …) 사용. API의 두 번째 특징을 보여준다.

 

3. REST(REpresentational State Transfer) API

: HTTP 프로토콜을 기반으로 하는 통신방법으로(기존 웹의 장점 최대화), 웹에 존재하는 모든 리소스에 고유한 URI를 부여해 접근(URL의 상위 개념)하는 웹의 정보통신 규칙 중 하나
 
  이번에는 application(소프트웨어)이 클라이언트가 되었다고 생각해보자. 클라이언트의 REST API 요청에 대해 서버는 클라이언트(어플리케이션)에게 REST API로 핵심 데이터만 전달한다. 이 때, 핵심 데이터는 view(HTML) 없는 JSON 데이터를 말한다.
 
  JSON 데이터를 받은 어플리케이션은 기존에 셋팅된 화면에 이 데이터만 넣어 사용자에게 보여주기 때문에, 프로그래밍 언어나 플랫폼에 종속적이지 않고, 다양한 브라우저나 디바이스에게 적용된다는 장점이 있다.
 
1) REST의 구성요소

  • 자원(Resource): 모든 리소스들은 고유한 ID를 가지고 있음 URL로 표현 >  Https://wwww.naver.com/memeber
  • 행위(Verb): 클라이언트가 각 자원에 요청하는 방법 HTTP Method로 표현 🠆 GET, POST, PUT, DELETE 등
  • 표현(Representation): 서버가 클라이언트에게 보내는 자원의 데이터 형태 JSON, XML 등으로 표현

  • URI로 요청을 보내면 representation에 정보값을 탑재한 response를 받아온다.
  • URL와 URI는 비슷하지만 URL은 PATH까지 위치하고 , URI는 최종 자원까지 위치한다
  •  REST API는 각 자원을 CRUD(Create, Read, Update, Delete) 방식으로 처리할 수 있도록 한다. RESTful 서비스는 JSON이나 XML 형식으로 데이터를 주고받으며, 클라이언트와 서버 간의 상호작용을 단순화한다.
  • POSTMAN은 REST API 개발과 테스트를 돕는 툴이다. HTTP 요청을 보내고, 응답을 확인하고, 헤더나 바디 값을 설정할 수 있는 기능을 제공한다. POSTMAN을 통해 REST API를 쉽게 테스트하고 확인할 수 있다.



2) JSON 객체(object) 구조와 표현

: 키-값의 쌍으로 이루어진 텍스트 기반 데이터 교환 형식

  • key와 value 구조가 기본 구조
  • key: 1) 반드시 문자열("큰따옴표"가 필수) 2) 중복 불가
  • value: 1) 다양한 데이터 타입(array 포함) 2) array: [대괄호]에 담기며, 다양한 값이 섞여서 사용
  •  JSON: {"name:"value"}. 문자열 key
  • Object: {name: "value"}. 객체 key

 

3) 타입변환

  • JSON to Object: JSON.parse(JSON)
  • Object to JSON: JSON.stringify(JSON)
user = '{ "name": "John", "age": 30 }'; //JSON
user = JSON.parse(user);

let user = {name: "John", age: 30}; //object
user = JSON.stringify(user);

 

정리하자면, HTTP, API, REST API는 모두 통신 규약이다. 일반적으로 웹 브라우저에서는 HTML을 포함한 HTTP 방식으로 서버에서 데이터를 가져오며, 어플리케이션에서는 REST API는 JSON 등의 방식으로 데이터만 가져온다.

API는 REST API와 조금 떨어뜨려 생각해야 이해하기 편하다. 원하는 서비스가 있는 서버에 대한 접근 방식, 위치, 접근 권한을 포함한 모든 것. openAPI의 경우 서버내 저장된 정보의 형식(받아올 데이터 정보값)을 가이드에 넣어 알려준다.

 
 

4. 웹스토리지

: 웹 브라우저가 데이터를 클라이언트 로컬에 저장할 수 있게 하는 기술. 문자열 키-값(Key-Value) 쌍으로 데이터를 저장하며,  재사용할 수 있다 (객체나 배열과 같은 복잡한 데이터는 JSON형식으로 변환해야 함).

 

1) 로컬 스토리지

: 데이터가 영구적으로 저장되고, 브라우저를 닫아도 데이터가 유지됨

  • 도메인 별로 저장되며, 같은 도메인이면 다른 탭 에서도 접근 가능
  • 사용자가 명시적으로 삭제할 수 있음

2) 세션 스토리지

: 데이터가 세션 동안만 저장되고, 브라우저 탭을 닫으면 데이터가 삭제됨

  • 같은 탭 내에서만 데이터 공유 가능
<!--로컬 스토리지-->
localStorage.setItem("key", "value"); // 저장
let value = localStorage.getItem("key"); // 불러오기
localStorage.removeItem("key"); // 특정 데이터 삭제
localStorage.clear(); // 모든 데이터 삭제

//로컬 스토리지에 데이터 저장
letname= "John";
letage= 20;
lethobby= ["game", "coding"];
localStorage.setItem("name", name);
localStorage.setItem("age", age);
localStorage.setItem("hobby", hobby);

//로컬 스토리지에서 데이터 불러오기
name= localStorage.getItem("name");
age= localStorage.getItem("age");
hobby= localStorage.getItem("hobby");
console.log(name, typeofname);
console.log(age, typeofage);
console.log(hobby, typeofhobby);

// 배열을 문자열로 변환하여 저장하기
hobby= ["game", "coding"];
localStorage.setItem("hobby", JSON.stringify(hobby));

// 저장된 배열을 불러와서 파싱하기
hobby= JSON.parse(localStorage.getItem("hobby"));
console.log(hobby, typeofhobby);


<!--세션 스토리지-->
sessionStorage.setItem("key", "value");
let value = sessionStorage.getItem("key");
sessionStorage.removeItem("key");
sessionStorage.clear();

 


 
참고문헌