[Web] 웹(Web), HTTP, REST API 이해하기 - 웹 서비스의 기본 구조 정리

 

 

웹 서비스를 개발하거나 사용하는 모든 과정은 결국 

웹(Web), HTTP, REST API라는 세 가지 개념 위에서 이루어지고 있습니다.

 

처음에는 각각이 별개의 기술이라 생각했는데

공부하면서 서로 긴밀하게 연결되어 있다는 것을 이해할 수 있었다.

 

이번 글을 통해 웹의 개념부터 HTTP, 그리고 REST API까지 핵심 내용을 정리해보고자 합니다.

1. Web

Web의 시작

웹은 1969년 미국 국방부의 ARPANET에서 출발했습니다.

전쟁 상황에서도 통신이 끊기지 않는 네트워크를 만들기 위한 연구가 오늘날 인터넷의 기반이 되었고,

이후 인터넷 위에서 정보를 공유하기 위한 시스템으로 웹(Web) 이 등장했죠.

 

웹은 단순히 인터넷이 아니라,

인터넷 위에서 데이터를 주고받기 위한 공통된 구조와 약속이라고 이해할 수 있습니다.

 

Web Service란?

웹 서비스는 인터넷을 통해 사용자에게 제공되는 서비스입니다.

대표적인 특징은 다음과 같은데요,

• 인터넷 기반으로 동작
• 여러 사용자가 동시에 이용 가능
• 운영체제와 기기에 독립적
• 브라우저 또는 설치형 클라이언트를 통해 접근 가능

우리가 사용하는 쇼핑몰, SNS, 은행 서비스 등이 모두 대표적인 웹 서비스입니다.

 

웹 서비스 동작 과정

웹 서비스는 기본적으로 

Request → Server Processing → Response

의 흐름으로 동작을 합니다.

 

조금 더 자세히 살펴보면,

1. 사용자가 화면(UI)을 조작한다.
2. 클라이언트가 HTTP 요청(Request)을 생성한다.
3. 서버가 요청을 처리한다.
4. 필요한 경우 데이터베이스를 조회하거나 저장한다.
5. 서버가 HTTP 응답(Response)을 반환한다.
6. 클라이언트가 결과를 화면(UI)에 표시한다.

즉, 사용자는 단순히 버튼을 누르는 것처럼 보이지만 내부에서는 이러한 과정이 반복적으로 수행되고 있어요.

 

** 주요 용어 **

용어	설명
User	웹 서비스를 사용하는 사람
Client	사용자의 입력을 받아 서버로 요청을 보내는 프로그램
Server	클라이언트의 요청을 처리하고 결과를 반환하는 프로그램
Database	데이터를 저장하고 조회·관리하는 시스템
Request / Response	클라이언트가 서버에 보내는 요청(Request)과 서버가 클라이언트에게 반환하는 응답(Response)
UI (User Interface)	사용자가 직접 보고 조작하는 화면 및 인터페이스
API (Application Programming Interface)	프로그램과 프로그램이 정해진 규칙에 따라 기능과 데이터를 주고받을 수 있도록 하는 인터페이스

 

2. HTTP

Client - Server 모델

웹은 Client-Server 구조를 기반으로 동작을 하고 있는데요.

• Client: 필요한 정보를 요청
• Server: 요청을 처리하고 결과를 반환

즉, 역할이 명확하게 분리되어 있기 때문에 여러 사용자가 하나의 서버를 동시에 이용할 수 있습니다.

 

HTTP란?

HTTP(HyperText Transfer Protocol)는

클라이언트와 서버가 데이터를 어떻게 주고받을 것인지 정한 통신 규칙이라고 합니다.

 

웹 브라우저에서 사이트에 접속하거나 앱에서 서버와 통신하는 대부분의 과정은 HTTP를 이용하고 있죠.

 

HTTP 메시지 구조

HTTP 메시지는 크게 세 부분으로 구성되고 있습니다.

 

1. Start Line

 

요청(Request)

GET /users HTTP/1.1

응답(Response)

HTTP/1.1 200 OK

 

 

Start Line에서의 응답 구조를 보게 되면, 

"상태코드 + 메시지" 구조로 리턴이 되는 것을 확인할 수 있습니다.

 

상태 코드만 확인해도 요청이 성공했는지, 인증에 실패했는지, 서버에서 문제가 발생했는지를 빠르게 파악할 수 있기에

잘 알아두면 좋을 것 같아요!

 

 ** 상태 코드 정리 **

상태 코드 범주	상태 코드	의미
2xx (성공)	200 OK	요청이 정상적으로 처리됨
	201 Created	리소스 생성 요청이 성공적으로 완료됨
	204 No Content	요청은 성공했지만 반환할 응답 본문(Body)이 없음
3xx (리다이렉션)	301 Moved Permanently	요청한 리소스가 새로운 URL로 영구적으로 이동됨
4xx (클라이언트 오류)	400 Bad Request	요청 형식이 잘못되어 서버가 처리할 수 없음
	401 Unauthorized	요청을 처리하기 위해 인증이 필요함
	403 Forbidden	접근 권한이 없어 요청이 거부됨
	404 Not Found	요청한 리소스를 찾을 수 없음
	409 Conflict	요청이 서버의 현재 상태와 충돌함
	422 Unprocessable Entity	요청 형식은 맞지만 유효성 검증에 실패함
5xx (서버 오류)	500 Internal Server Error	서버 내부 오류가 발생함
	502 Bad Gateway	게이트웨이 또는 프록시 서버가 잘못된 응답을 받음
	503 Service Unavailable	서버 과부하 또는 점검으로 현재 서비스를 제공할 수 없음

 

2. Header - 메타데이터 저장

• Content-Type
• Authorization
• Content-Length

등의 정보가 포함됩니다.

 

3. Body - 실제 전달 데이터

 

회원가입 정보나 게시글 내용처럼 필요한 데이터는 Body에 JSON 형태로 전달하는 경우가 많습니다.

 

curl을 이용한 HTTP 요청

지금까지 HTTP 구조를 살펴봤다면, 이번에는 직접 HTTP 요청을 보내보겠습니다.

 

HTTP 요청은 curl 명령어를 통해 쉽게 확인할 수 있는데요,

여기서 curl은 HTTP 요청을 직접 테스트하거나 API를 확인할 때 매우 자주 사용하는 도구입니다.

 

만약, 헤더만 조회를 한다면?

curl -I example.com

 

만약, 자세한 요청과 응답 확인하고 싶다면?

curl example.com -v

 

혹은, JSON 데이터를 포함한 POST 요청을 시도해보고자 한다면 다음과 같은 구조로 작성을 해주면 됩니다.

curl -X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d "{\"email\":\"test@example.com\",\"password\":\"1234\"}"

 

인터넷, 웹, HTTP의 관계

세 가지 개념은 다음과 같이 정리할 수 있어요.

• 인터넷 : 가장 큰 네트워크 인프라
• 웹(Web) : 인터넷 위에서 정보를 제공하는 시스템
• HTTP : 웹에서 데이터를 주고받는 통신 규칙

즉, 인터넷 위에서 웹이 동작하고, 웹에서는 HTTP를 이용해 데이터를 주고받는 것이라 생각하면 쉽습니다!

 

그렇다면 실제 HTTP 요청은 어떤 방식으로 표현이 될까요?

 

클라이언트는 요청을 보낼 때

“무엇(Resource)” 과 “무엇을 할 것인가(Action)” 를 함께 전달하는데요.

 

-   GET : 조회
-   POST : 생성
-   PUT/PATCH : 수정
-   DELETE : 삭제

조회 조건은 Query Parameter를 사용하고, 

생성이나 수정 데이터는 Request Body에 담습니다.

 

 

3. REST API

URL과 HTTP Method로 요청의 의도 표현하기

앞에서 HTTP는 클라이언트와 서버가 데이터를 주고받기 위한 통신 규칙이라고 살펴보았는데요,

그렇다면 실제 HTTP 요청은 어떤 방식으로 표현될까요?

 

REST API에서는 클라이언트가 서버에 요청을 보낼 때

“어떤 자원(Resource)에 대해 무엇을 할 것인지(Action)”를 명확하게 표현합니다.

 

이를 위해 URL은 자원(Resource)을 나타내고, HTTP Method는 수행할 동작(Action)을 나타냅니다.

 

일반적으로 자원은 복수형 명사 형태의 URL로 표현하고,

행위는 CRUD(Create, Read, Update, Delete)에 대응하는 HTTP Method로 표현합니다.

HTTP Method	역할	예시
GET	데이터 조회(Read)	GET /users
POST	데이터 생성(Create)	POST /users
PUT / PATCH	데이터 수정(Update)	PUT /users/1
DELETE	데이터 삭제(Delete)	DELETE /users/1

 

예를 들어, 사용자 목록을 조회하고 싶다면 GET /users를 사용하고,

새로운 사용자를 생성하려면 POST /users를 사용합니다.

또한 123번 주문을 삭제하는 요청은 DELETE /orders/123과 같이 표현합니다.

 

REST API에서는 URL 자체에 행위를 포함하기보다는,

URL은 자원을 표현하고 HTTP Method가 행위를 표현하는 방식을 권장합니다.

이러한 규칙을 따르면 API의 의미가 더욱 명확해지고, 일관성 있는 설계와 유지보수가 쉬워지기 때문이죠.

 

이제 REST API가 무엇인지에 대해 자세히 알아보겠습니다.

API란?

API(Application Programming Interface)는 

서로 다른 프로그램이 기능과 데이터를 주고받기 위한 약속입니다.

클라이언트는 API를 통해 서버의 기능을 사용할 수 있죠.

API가 프로그램 간의 약속이라면?

REST API는 이러한 API를 웹 환경에 맞게 설계하는 대표적인 방식입니다.

REST API란?

REST API는 URL은 자원(Resource)을 표현하고,

HTTP Method는 수행할 동작(Action)을 표현하도록 설계합니다.

 

예를 들어

-   GET /users
-   POST /users
-   PUT /users/1
-   DELETE /users/1

처럼 URL에는 행위를 넣지 않고 Method로 의도를 표현하는 것이 핵심입니다.

대부분의 기능은 이러한 CRUD 방식으로 표현할 수 있습니다.

하지만 로그인이나 결제 승인처럼 특정 동작 자체가 목적이 되는 기능은
예외적으로 POST를 사용하는 경우가 많습니다.

-   POST /auth/login
-   POST /payments/1/confirm
-   POST /orders/123/cancel

 

Insights

이번 내용을 공부하면서 웹 서비스가 단순히 화면을 보여주는 것이 아니라 클라이언트, 서버, HTTP, 데이터베이스가 서로 역할을 나누어 동작하는 구조라는 것을 이해할 수 있었다.

또한 REST API는 URL과 HTTP Method만으로도 요청의 의미를 명확하게 표현할 수 있도록 설계하는 방식이라는 점이 인상 깊었다. 앞으로 백엔드 API를 설계하거나 프론트엔드에서 서버와 통신할 때 이번에 정리한 기본 개념들이 중요한 기반이 될 것이라고 생각한다.

---

느낀점

특히 인터넷, 웹, HTTP, REST API가 각각 독립된 개념이 아니라 서로 연결되어 하나의 웹 서비스를 구성한다는 점이 가장 인상적이었다. 또한 URL은 자원을 표현하고 HTTP Method는 행위를 표현한다는 REST API의 설계 원칙을 배우면서, 왜 API를 일정한 규칙에 맞게 설계해야 하는지 이해할 수 있었다. 앞으로 프로젝트에서 API를 설계하거나 서버와 통신할 때 단순히 기능을 구현하는 것을 넘어, 이러한 표준적인 설계 원칙을 고려하며 개발하는 습관을 가져야겠다고 느꼈다.

 

이번 학습을 통해 평소에 자주 사용하던 웹 서비스가

라이언트, 서버, HTTP, 데이터베이스가 서로 역할을 나누어 동작하는 구조라는 것을 이해할 수 있었습니다.

 

또한 REST API의 설계 원칙을 배우면서, 왜 API를 일정한 규칙에 맞게 설계해야 하는지도 알게되었습니다.

 

앞으로 프로젝트에서 API를 설계하거나 서버와 통신할 때, 단순히 기능 구현에 그치지 않고

이러한 표준적인 설계 원칙을 고려하면서 개발하는 습관을 가져야겠다고 느꼈습니다!

---