브라우저, 서버, API, HTTP, Ajax 개념 정리

출처 : 코드스테이츠

 

서버에 들어가기 앞서 API와 UI의 개념을 알고 넘어가자.

 

API (Application Programming Interface)
- 프로그래밍 되어 있는 애플리케이션과 의사소통 가능한 매개체

UI (User Interface)

-유저와 의사소통 가능한 매개체

 

여기서 Interface를 한 마디로 말하자면, 의사소통이 가능하도록 만들어진 매개체(접점)이다!

 

즉 UI라는 것은 일반인들이 휴대폰, 컴퓨터를 접할 때 가장 많이 접하는 부분이다.

보기 좋게 직관적으로 구성되어 있는 웹사이트에서 클릭할 수 있는 버튼들과 입력할 수 있는 창이 바로 UI의 예라고 볼 수 있다.

 

그리고 그 일반인들이 UI를 사용할 수 있게 만들어 주는 개발자들이 접하는 것이 바로 API이다.

UI를 만들기 위해서 개발자들은 소프트웨어를 제어할 수 있는 API를 활용한다.

 

아무튼, API에 대한 설명은 앞으로 더 자세하게 살펴볼테니 여기까지만 그림을 그려놓고 서버 개발에 필요한 환경들이 어떤 것이 있는지 하나씩 알아보자.

 

 

먼저 전체적인 웹 아키텍처의 모습은 이렇게 그려볼 수 있다.

 

 

 

여기서 클라이언트와 서버 먼저 자세하게 뜯어보겠다.

 

 

각 키워드들을 자세하게 알아보자.

 

 

먼저 브라우저가 있다.

 

컴퓨터는 0과 1로 구성된 정보만 알아들을 수 있다.

그런데 우리가 코딩을 할 때, 0과 1로만 사용해서 코딩을 하는 것이 아닌데도 어떻게 웹을 만들 수 있었던걸까?

바로 브라우저가 있기 때문이다.

자바스크립트, HTML, CSS 등의 다양한 도구들로 작성한 코드를 해독해서 컴퓨터가 알아들을 수 있게 만들어준 것이 브라우저이다.

 

자세한 내용은 여기서 확인할 수 있다.

 

 

그리고 서버가 있다.

 

서버는 한 마디로 자원을 serve(제공)하는 주체이다.

서버는 곧 스타벅스라고 생각하면 편하다.

앞서 설명한 그림에 따르면 웹 아키텍쳐는 크게 클라이언트 - 서버 - 데이터베이스로 나뉘는데

여기서 클라이언트는 커피를 먹고 싶어하는 손님

데이터베이스는 커피 원두라고 하면

서버가 그 중간에서 커피를 만들어주는 역할을 하는 것이다.

 

즉, 클라이언트의 요청에 따라 맞는 데이터 베이스를 꺼내와서 제공하는 것이 바로 서버이다.

 

 

 

이제 API를 다시 알아보자.

 

서버자원을 클라이언트에서 잘 가져다 쓸 수 있게 만들어 놓은 인터페이스 (메뉴판)

예를 들어 api를 불러오고, 정보를 내보내 주기도 하는 함수인 fetch 를 사용할 수 있다.

 

 

HTTP란?

HTTP는 상당히 확장 가능한 프로토콜이다.

HyperText Transfer Protocol 의 약자

여기서 Protocol에 초점을 두면 되는데 Protocol은 규약, 규칙이라는 뜻이다.

그러니까 클라이언트와 서버가 통신할 때 사용하는 규칙이다.

클라이언트와 서버는 개별적인 메시지 교환에 의해서 통신을 한다.

보통 브라우저인 클라이언트에 의해서 전송되는 메시지를 요청(Request) 이라고 부르며

그에 대해 서버에서 응답으로 전송되는 메시지를 응답(Response) 이라고 부른다.

 

작동방식, 속성, 메소드에 대해서 알아보자.

 

HTTP의 작동방식은 요청과 응답으로 이루어진다는 것이다.

요청이 들어오면 무조건 응답을 주어야 한다. 응답이 없다면 그것은 error이다.

요청에 대한 적절한 응답이 없더라도 없다는 응답을 주어야 한다.

 

HTTP의 구성은 헤더와 바디로 이루어져 있다.

그러니까 요청과 응답 각각이 헤더와 바디로 구성된다는 것이다.

헤더: 어디서 보내는 요청인가, 컨텐츠 타입은 무엇인가, 어떤 클라이언트를 이용해서 보냈는가

바디: 서버에 데이터를 보내기 위한 공간으로 활용된다.

 

HTTP의 속성은 두 가지가 있다.

속성1. stateless: 각 요청은 모두 독립적이다. 문맥이 형성되지 않는다. (챗봇 심심이 같은 느낌)

즉 상태를 저장하지 않는다.

요청1:  밥 먹을래?
응답1: 좋아!
요청2: 뭐 먹을래?
응답2: 뭘?

 

속성2. connectionless: 한번의 요청에는 한번의 응답을 한다. 응답을 안하면 안됨. 응답을 한번 보내면 연결이 끊어진다.

 

HTTP 메소드는 대표적으로 4가지가 있다.

get: 서버에 자원을 요청,

post: 서버에 자원을 생성,

put: 서버의 자원을 수정,

delete: 서버의 자원을 제거

 

HTTP에 대해 조금 더 구체적으로 알아보자면 응답할 때 상태 코드 (status code) 라는 것이 함께 보내진다.

크게 5가지로 나뉘는데

• 1xx (정보): 요청을 받았으며 프로세스를 계속한다

• 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다

• 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다

• 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다

• 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다

가장 많이 쓰이는 상태코드에는 

200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.

400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.

404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.

등이 있다.

 

HTTP에 대해서 추가적으로 더 알아보면 좋을 정보에는

*HTTP 헤더 분석
헤더의 종류에는

General Header : 요청과 응답 모두에 적용되지만, 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.

Request Header : 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

Response Header : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더

Entity Header : 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더

로 컨텍스트에 따라 그룹핑할 수 있다.

 

 

*브라우저의 network 탭을 통해 일어나는 일들 -> 동적 렌더링을 할 때 어떤 통신을 하고 있는지 알 수 있다.

이 정도가 있을 것이다.

 

 

 

Ajax란? (Asynchronous Javascript and XML)

 

예전 웹사이트에서는 one.html이라는 파일에서 요청을 보내면 two.html이라는 파일을 새롭게 제공해서 응답을 보냈다.

하지만 이런 방식은 너무 비효율적이다.

요청을 보냈을 때, 페이지에서 필요한 부분의 화면만 업데이트해서 응답을 준다면 훨씬 시간적으로나 메모리적으로 효율적일 것이다.

이것이 바로 dynamic web page 라는 것이다. (단순한 web page가 아닌 web app의 등장!)

dynamic web page는

서버와 자유롭게 통신할 수 있고,
 => XMLHttpRequest 의 등장

페이지 깜빡임 없이 seamless하게 작동한다.
 => Javascript와 DOM 이용

이 두가지를 합쳐서 Ajax 라고 하는 개념이 등장한 것이다.

여기서 Ajax를 쓰기 쉬운 표준 API를 만들자! 해서 만들어진 것이 fetch API이다.

 

하지만 XMLHttpRequest도 많이 쓰이기 때문에 두 가지의 차이점을 분명히 확인할 것

참고 링크:

MDN using fetch

that’s so fetch

this api is so fetching

 

fetch를 왜 쓰나요?
뜻: 어떤 것을 가져오는 function이다.
서버자원을 가지고 오기 위해서 쓰는 것이다.
XMLHttpRequest/ Jquery ajax/ fetch 등등