자바 스프링 부트[JAVA Spring BOOT] #1 - 서버

KeyWord :

호스트, 도메인, IP, HTTP 상태코드, Statefull, Stateless, 세션, 쿠키

 

 

0. 클라이언트 - 서버

 

웹 서비스를 예로 들어 설명하자면, 흔히 컴퓨터, 즉 데스크탑이나 노트북으로 자주 사용하는 사이트들이 웹 사이트입니다. 이때 클라이언트란 서버의 서비스를 받아 사용하는 장치 혹은 프로그램을 의미합니다. 그렇다면 서버는 무엇일까? 서버는 데이터를 포함하거나 네트워크의 다른 컴퓨터에서 엑세스하는 기능을 제공하는 컴퓨터입니다. 

 

 

일반 서버의 유형으로는

• 파일을 저장하는 파일 서버
• 이름과 주소를 저장하는 이름 서버
• 프로그램과 애플리케이션을 저장하는 애플리케이션 서버
• 인쇄 작업을 해당 대상으로 스케줄하고 지시하는 인쇄 서버

가 있습니다.

 

만약 www.naver.com  이라는 URL 로 요청을 보내면 해당하는 웹서버에 요청이 전송되고, 해당 서버는 해당 도메인의 사이트를 찾아 우리에게 익숙한 네이버 사이트를 화면에 띄워줍니다. 이 대화는 API 를 통해서 이루어집니다.

 

이때, 도메인(Domain, * keyword)과 호스트(Host, * keyword)는 무엇일까?

 

호스트는 네트워크/인터넷 호스트(network/internet host)를 의미하며 네트워크/인터넷에서 호스트는 네트워크/인터넷을 통해 다른 컴퓨터들과 쌍방향 통신이 가능한 컴퓨터, 즉 컴퓨터 네트워크/인터넷에 연결된 컴퓨터나 기타 장치를 말합니다.

 

이때 호스트는 다른 호스트와 데이터를 주고 받기 위해, 자신들을 구분하는 특수한 번호를 갖는데, 이를 IP(* keyword) 주소라고 합니다.

 

하지만 IP 주소같은 기계적인 이름은 일반인이 읽기 어렵기 때문에 이해할 수 있는 이름으로 호스트 네임을 만듭니다.

 

만약 자신의 컴퓨터로 서버를 설정한다면 http://localhost:3000 으로 접속할 수 있는데, 이때 localhost 는 호스트 자기 자신을 가르키는 호스트 네임입니다.

 

호스트 네임은 각 네트워크 디바이스(예를 들어, 컴퓨터) 에 할당되는 이름입니다. 이와 달리 도메인 네임은 네트워크에 부여되는 이름인데, 인터넷과 같은 외부에서 네트워크에 접속하려면 도메인이 필요합니다.

 

예를 들어 mail.naver.com 이나 comic.naver.com 이라는 도메인 네임에서 mail 과 comic 은 각각의 서비스를 구분하기 위한 호스트 네임입니다. 즉, 해당 URL 을 수신하는 서버는 서로 다른 호스트임을 알 수 있습니다.

 

 

 

 

1. API

 

API 란 Application Programming Interface 로 한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법입니다. 식당에 있는 메뉴판과 유사합니다. 식당의 요리사와 손님의 관계에서 메뉴에 있는 음식만 요리사는 만들 수 있고, 손님은 메뉴판에 존재하는 음식만 주문할 수 있습니다. 요리사와 손님의 대화 형식인 것입니다.

 

저희는 항상 API 로 요청을 보내며 웹, 앱 서비스를 사용해왔습니다. 해당 API 요청들을 보기 좋고 간편하게, 사용자 친화적이게 구현해놓는 것이 클라이언트 개발자들이 하는 일입니다. 

 

2. HTTP 프로토콜

 

HTTP 는 Hypertext Transfer Protocol 의 약자로 클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜입니다. 보통 HTML 이나 JSON 의 형태로 데이터를 주고 받습니다. 클라이언트가 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있더록, 일정한 패턴을 지닌 문자열을 생성해서 보내면 클라이언트는 그를 해석해 데이터를 자기만의 방식으로 온전히 저장, 표시할 수 있게 됩니다.

 

HTML 과 같은 XML 방식은 JSON 에 비해 상대적으로 읽기 어렵고, 소프트웨어에서 파싱 및 생성하기도 상대적으로 어렵기 때문에 JSON 방식을 많이 사용합니다.

 

JSON 은 key 와 value 값으로 이루어져 있는 텍스트의 형식입니다. value 값으로 배열, Boolean, NULL, 숫자, 객체, 문자열이 나올 수 있습니다.

 

예시

{

"Influencers" :   [ 
{
 "name" : "Jaxon", 
 "age" : 42, 
 "Works At" : "Tech News"
}

{
 "name" : "Miller", 
 "age" : 35
 "Works At" : "IT Day"
}

] 
}

 

서버와 클라이언트는 HTTP 에 기반하여 요청과 응답을 주고 받습니다.

이때 요청(REQUEST)과 응답(RESPONSE)은 Header 와 Body 로 구분되어 있습니다.

https://velog.io/@bky373/Web-HTTP%EC%99%80-HTTPS-%EC%B4%88%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC

[Web] HTTP와 Request, Response의 개념 이해

 

REQUEST Method 의 종류로는

• GET: 데이터를 조회할 때 사용
• POST: 데이터의 생성을 요청할 때 사용
• PUT: 전체 데이터의 수정을 요청할 때 사용
• PATCH: 일부 데이터의 삭제를 요청할 때 사용
• DELETE: 데이터의 삭제를 요청할 때 사용

가 있습니다.

 

HTTP Response, HTTP 응탑 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나눠지는데,

• 정보를 제공하는 응답(1xx)
• 성공적인 응답(2xx)
• 리다이렉트(3xx)
• 클라이언트 에러(4xx)
• 서버 에러(5xx)

가 있습니다. 자세한 코드는 아래 사이트에 있습니다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTP 상태 코드 - HTTP | MDN

 

 

(* Stateful, Stateless, 쿠키, 세션 keyword 는 접은글 안에 정리했습니다.)

HTTP 통신은 기본적으로 Statless 한 통신 방식으로 단순히 요청에 맞는 응답을 반환하고 연결을 끊어버립니다. 서버와 클라이언트간의 통신은 크게 Stateful(상태 유지) 와 Statless(상태 유지x) 방식으로 나뉩니다.

 

1. Stateful(* keyword)

 

상태 유지라 함은 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미합니다. 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데에 있어서, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태입니다.

 

클라이언트의 정보를 기억한다는 말은 어딘가에 정보를 저장하고 통신할 때마다 읽는다는 뜻입니다. 이러한 정보들은 일반적으로 브라우저의 쿠키(Cookie) 에 저장되거나, 서버의 세션(Session) 메모리에 저장되어 상태를 유지합니다.

 

대표적인 Stateful 구조를 따르는 프로토콜로 TCP 의 3-way handshaking 과정이 있습니다.

 

Stateful 구조의 문제점은 해당 서버가 멈추거나 여러 이유로 해당 서버를 못 쓰게 되어 다른 서버를 사용해야 할대 발생합니다. 왜냐하면 새로운 서버에서는 이전 서버에서 가지고 있던 상태값들을 가지고 있지 않기 때문입니다.

 

2. Stateless(* keyword)

 

무상태는 반대로 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미합니다. 해당 구조에서 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것입니다. 즉, 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할 때 데이터를 실어 보내는 것입니다.

 

Stateless 특징

Stateless 특징

 

그래서 대량의 트래픽 발생 시에도 서버 확장을 통해 대처를 수월하게 할 수 있다는 장점도 있습니다.

서버 확장

 

무상태의 단점으로는 클라이언트의 요청에 상대적으로 더 많은 데이터가 소모된다는 점입니다.

매번 요청할 때마다 자신의 부가정보를 줘야하기 때문입니다.

 

예시

 

이에 쿠키(Cookie)(* keyword) 와 세션(Session)(* keyword) 이 등장합니다.

(* 쿠키는 클라이언트 단에 정보 저장, 세션은 서버 단에 정보 저장)

https://interconnection.tistory.com/74

쿠키와 세션 개념

3. Restful API

 

말 그대로 Rest 하게 만들어진 API 입니다. 

 

REST 는 다음과 같은 3가지로 구성이 되어있습니다.

 

1. 자원(Resourse): HTTP URI, ex) www.elancer.co.kr/blog/view?seq=40

2. 자원에 대한 행위(Verb): HTTP Method, ex) POST, GET, PUT, DELETE, PATCH ...

3. 자원에 대한 행위의 내용(Representations): HTTP Message Pay Load, ex) JSON, XML

 

HTTP URI 를 통해 자원을 명시하고 HTTP Method 를 통해 해당 자원에 대한 CRUD Operation(* Creat, Read, Update, Delete) 을 적용합니다.

 

REST 의 특징으로는 크게 5가지가 있습니다.

 

1. 균일한 인터페이스:
   • 요청이 어디서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다. REST API 는 사용자의 이름이나 이메일 주소등의 동일한 데이터 조각이 오직 하나의 URI(Uniform Resource Indentifier) 에 속함을 보장해야 합니다. 리소스가 너무 클 필요는 없지만, 이는 클라이언트가 필요로 하는 모든 정보를 포함해야 합니다.
2. 클라이언트-서버 디커플링:
   • REST API 디자인에서 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI 이며, 다른 방법으로는 상호작용할 수 없습니다.
3. Stateless:
   • REST API 는 stateless 입니다. 즉, REST API 는 서버측 세션을 필요로하지 않습니다.
4. 캐싱 가능성:
   • 가능하면 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 합니다. 또한 서버 응답에서는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 이의 목적은 서버측의 확장성 증가와 함께 클라이언트 측의 성능 향상을 동시에 얻는 것입니다.
5. 계층 구조 아키텍처:
   • REST API 에서는 호출과 응답이 서로 다른 계층을 통과합니다. 통신 루프에는 다수의 서로 다른 중개자가 있을 수 있습니다. REST API 는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 합니다.

 

자세한 REST API 의 설계 예시는 다음과 같습니다.

 

1. URI 는 동사보다는 명사를, 대문자 보다는 소문자를 사용하여야 합니다.

• BAD Example: http://hw-hk.tistory.com/Running
• GOOD Example: http:// hw-hk.tistory.com/run

2. 마지막에 슬래시(/) 를 포함하지 않습니다.

• BAD Example: http://hw-hk.tistory.com/test
• GOOD Example: http:// hw-hk.tistory.com/test/

3. 언더바(_) 대신 하이픈(-)을 사용합니다.

• BAD Example: http://hw-hk.tistory.com/test_blog
• GOOD Example: http:// hw-hk.tistory.com/test-blog

4. 파일확장자는 URI 에 포함하지 않습니다.

• BAD Example: http://hw-hk.tistory.com/photo.jpg
• GOOD Example: http:// hw-hk.tistory.com/photo

5. 행위를 포함하지 않습니다.

• BAD Example: http://hw-hk.tistory.com/delete-post/1
• GOOD Example: http:// hw-hk.tistory.com/post/1