Web Architecture / 개요 / Browser, Server, API, HTTP, Ajax

브라우저

d2.naver.com/helloworld/59361

 

브라우저의 주요 기능은 사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는 것이다.

다시 말해 서버 컴퓨터 내의 데이터들을 수신하고, 해석해서 사용자가 알아볼 수 있도록 제공 및 관리하는 서비스이다.

 

브라우저는 HTML과 CSS 명세에 따라 HTML 파일을 해석해서 표시하는데, 이 명세는 웹 표준화 기구인 W3C(World Wide Web Consortium)에서 정한다.

 

링크에 나오는 것처럼, 브라우저는 사용자 인터페이스, 브라우저 엔진, 렌더링 엔진, 통신, UI 백엔드, 자바스크립트 해석기, 자료 저장소로 이루어져있다.

 

 

 

 

서버-클라이언트-데이터베이스

 

클라이언트 : 사용자가 쓰는 컴퓨터 또는 프로그램을 의미한다. 어떤 정보를 얻기 위해 서버에 요청을 하고, 서버에서 오는 신호를 해석하여 사용자에게 보여주는 역할을 한다.

 

서버 : 클라이언트의 요청을 처리하고, 정보나 자료가 저장되어있는 데이터베이스에 접근하여 데이터를 가지고 온다. 이후 클라이언트에 해당 데이터를 전송해주는 중개자 역할을 한다.

 

데이터베이스 : html 문서, 사진 등 여러 자원들이 저장되어 있는 곳이다.

 

 

 

 

HTTP

 

HTTP(Hyper Text Transfer Protocol)는 정보를 주고 받는 규약이다. 이 규약을 통해서 클라이언트는 서버에 요청을하고, 서버는 클라이언트의 요청에 응답을 하게 되어 있는 구조다. 요청과 응답은 header와 body로 구성되어 있다. header에는 요청을 보내는 위치, 어떤 내용을 요청하는지, 어떤 브라우저를 통해서 요청하는지 등의 데이터에 대한 정보가 담긴다. body에는 header에 맞는 실제 데이터가 들어간다. http에는 다음 2가지의 속성이 있다.

 

1. 비연결성(Connectionless)

클라이언트에 의해 요청을 받은 서버가 응답을 마치면, 서로의 연결을 끊어버리는 특징을 갖는다. 이것은 불특정 다수를 대상으로 서버가 연결을 계속 유지해야한다면, 많은 리소스가 발생하기 때문이다.

 

2. 무상태(Stateless)

http의 각 요청사항은 서로 독립적이고, 그 요청사항을 저장하지 않는다. 즉, A라는 클라이언트가 서버에 한 번 요청을 했다고 해서, 서버가 A 클라이언트의 이력이나 상태를 기억하지는 않는다는 것이다. 편의를 위해 클라이언트의 정보를 기억해야 하는 경우가 많은데, 이것을 쿠키, 세션, OAuth, JWT 등으로 가능하게 할 수 있다.

 

비연결성과 무상태에 대한 더 자세한 내용은 다음 블로그에 잘 나와있다.

victorydntmd.tistory.com/286

 

HTTP의 대표적인 메소드는 GET, POST, PUT, DELETE이다. 특정 데이터를 갖고 어떤 행동을 할 것인가에 대한 내용이다.

 

• GET : 서버에 데이터를 요청한다.
• POST : 서버에 새로운 데이터를 작성한다.
• PUT : 서버에 작성된 데이터를 수정한다.
• DELETE : 서버에 작성된 데이터를 제거한다.

MDN 문서에 더욱 상세한 내용이 기술되어 있다.

developer.mozilla.org/ko/docs/Web/HTTP/Methods

 

 

HTTP 상태 코드

 

클라이언트가 서버에 요청을 보내면, 서버는 반드시 그에 대한 응답을 보내주게 되어있다. 이런 응답은 세 자리의 숫자 코드로 표현되는데, 이것을 HTTP 상태코드라 한다. 모든 HTTP 응답 코드는 5개의 클래스로 구분된다.

 

• 1xx(정보) : 요청을 받았으며, 프로세스를 계속한다.
• 2xx(성공) : 요청을 성공적으로 받았고, 인식 후 성공적으로 처리했다.
• 3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요하다.
• 4xx(클라이언트 오류) : 요청의 문버빙 잘못되었거나, 요청을 처리할 수 없다.
• 5xx(서버 오류) : 클라이언트는 요청이 명백하나, 서버가 요청을 처리할 수 없다.

상세내용은 위키백과를 참조한다.

ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C

 

 

아래 그림은 위키백과의 HTTP에 대한 설명 중 요청과 응답양식에 대한 예제이다.

클라이언트 요청은 GET method를  HTTP 1.1 방식을 사용하여 요청하고, application/json 형태의 data 형식으로 요청하는 내용이다. GET method이기 때문에, 서버에서 데이터를 받아오는 것이라서 HTTP의 header 부분만 있고 body 부분은 없다.(반드시 header만 있어야 되는 것은 아님)

 

서버 응답은 header 부분에 200/ OK로 정상적으로 요청을 받아들였음을 나타내고 있다. 그리고 Date, Content-type 등을 명시하고 있다. header 부분 에서 한 줄 띄우고 body 부분이 작성되어 있음을 볼 수 있다. 실제로 전송되는 HTML 코드이다.

 

출처 - https://ko.wikipedia.org/wiki/HTTP

HTTPS

 

보통 클라이언트와 서버는 문자열(텍스트)로 된 정보를 주고 받게 되는데, 이것을 다른 사람도 볼 수 있는 형태이기 때문에, 내용이 노출되는 보안 위험성이 존재한다. http와 유사하지만 모든 내용을 암호화하여 데이터를 공유하는 방식이 https이다. https는 SSL 기반의 통신이다.

 

 

 

API

 

서버에 어떤 데이터가 있는지를 표시해놓은 것이다. 흔히들 메뉴판이라고 비유적으로 설명한다. 

사용자가 특정 명령어를 통해서 서버에 있는 데이터를 요청하면, API는 그 데이터에 맞는 양식(interface)으로 데이터가 출력되게 해주는 것이다. 마치 UI가 기계의 내부에 있는 데이터와 사람간의 상호작용을 할 수 있도록 꾸며진 입,출력 양식(interface)인 것처럼, API는 서버 내부에 있는 데이터와 클라이언트가 좀 더 편하게 상호작용 할 수 있도록 꾸며진 프로그램, 양식인 것이다. 정확한 사례는 다음 '생활코딩' 링크에서 확인할 수 있으며, 영상 10분 정도까지만 보면 어느 정도 이해할 수 있다.

www.youtube.com/watch?v=Z4kH0IZVT-8&t=95s

 

인터넷 주소창에 javasciript:alert("Hello world")     입력 시 나오는 경고창

간단하게는 다음 경고창의 UI를 설정해준 것이 바로 API라고 할 수 있다. javascript에서 "alert('Hello wolrd')" 라고 입력하면 경고창이 웹페이지의 '중앙에 나타나고', '확인 버튼이 나오며', '확인 버튼에 마우스를 갖다대면 파란색으로 변하는' 등 여러가지의 요소들이 설정되어 있다. 즉, 사용자에게 단순히 "Hello world"라는 경고 text만 전달할 뿐 아니라 사용자가 보기 편하도록 미리 UI 환경을 설정해놓은 것이다. 이런 것이 API라고 볼 수 있다.

 

Rest API

REpresentational State Transfer, server를 만들 때 client가 사용할 API를 어떻게 만들어야 되는지에 대한 제약 사항을 말한다. 다만 그 제약 사항이 명확하고 표준화된 것은 아니라서, 무엇이 Restful한 것인가에 대해서는 아주 논쟁이 많은 주제이다.

 

그럼에도 불구하고, client가 여러 곳의 source(server)로부터 데이터를 가져와야 하는 상황이 많은데, 이 때마다 API 양식이 다르면 불편하고 비 효율적이기 때문에 RESTful API가 필요하다. 대표적인 REST의 6가지 제약조건은 다음과 같다.

 

• Client-Server
• Stateless
• Cacheable
• Uniform interface 
• Layered system
• Code-on-demand(Optional)

 

1. Client-Server 구조

server는 API를 제공하고, client는 사용자 인증이나 로그인 정보, 세션 등을 직접관리하는 구조로 각각의 역할을 확실히 구분하여 개발 내용을 명확히 하고 의존선을 줄여나가야 된다.

 

2. Stateless

HTTP에서 언급한 내용으로 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다는 의미이다.

 

3. Cacheable

HTTP 웹 표준을 그대로 적용하여 HTTP가 가진 caching 기능을 적용할 수 있게 해야한다는 의미이다. Caching 이란 client와 server 간의 통신에서 매번 데이터 전체를 받아오면 시간과 비용이 발생하므로 일부를 저장해놓는다는 것이다.

 

4. Uniform Interface

resource에 대한 UI가 통일성이 있어야 한다는 의미이다. 요구되는 바는 다음과 같다.

• Identification of resources
• manipulation of resources through representation
• self-descriptive messages
• Hypermedia As The Engine Of Application State(HATEOAS)

resource의 구분이 명확해야하고, 정보의 표현을 통한 resource의 조작이 가능해야하며, REST API만 보고도 쉽게 이해할 수 있는 자체 표현 구조(self-descriptive)를 지녀야 하며, 한 리소스에서 다른 리소스로 이동할 수 있는 링크들이 존재(HATEOAS)해야 한다.

추상적인 이해말고 정확한 이해를 위해서는 더 자세히 공부하고, 실제 API를 제작해보는 경험이 필요할 것이다.

 

대표적 가이드 라인 :

1. resource를 나타내는데 동사가 아닌 명사를 사용하라.

2. CRUD에 해당하는 기능 4개만 사용하라.

3. filter가 필요하면 query selector를 사용하라.(endpoint를 따로 만들지 말고)

 

참조 - restfulapi.net/

deview.kr/2017/schedule/212

 

5. Layered system

계층화된 시스템 아키텍쳐를 사용해서, 각 계층간에 마음대로 상호작용을 하는 것이 아니라 제한을 두어 Interface를 일원화한다.

 

6. Code on demand(optional)

원래는 server로 부터 xml, json 형태의 데이터를 받아서 client가 재가공하게 되는데, code on demand는 client에 보내는 데이터를 실행 가능한 code 형태로 보내서 client에서 실행할 수 있도록 하는 것을 말한다.

AJAX

 

AJAX(Asynchronous JavaScript and XML)는 웹페이지를 비동기적으로 반응시키기 위한 기법이다. 특정한 도구를 표현하는 용어가 아니고, HTML, CSS, XMLHttpRequest, DOM, Javascript 등의 조합으로 비동기적인 처리를 하는 기법을 말한다.