Notice
Recent Posts
Recent Comments
Link
«   2026/03   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

Tomato Basil

3-1. 백엔드 기초, API 본문

DataBase

3-1. 백엔드 기초, API

salt pepper 2024. 4. 22. 23:47

백엔드 기초부터 다시 알아보자.

 

기본적인 구조는

클라이언트 -(요청)-> 웹서버

클라이언트 <-(응답)- 웹서버

이다.

 

구체적으로는 

클라이언트 -(요청)-> 웹서버 -(요청)-> 웹 어플리케이션 서버 -(요청)-> 데이터베이스

클라이언트 <-(응답)- 웹서버 <-(응답)- 웹 어플리케이션 서버 <-(응답)- 데이터베이스

이다.

 

클라이언트는 

1) 사용자

2) 프론트엔드

로써, 서버에게 요청할 수 있다.

 

웹 서버(Web Server)는 정적인 페이지를 처리한다.

웹 어플리케이션 서버(Web Application Server)는 동적인 페이지를 처리한다.

'정적인 페이지'는 화면의 내용과 데이터에 변동이 없는 페이지, (프론트 부분이라고 봄)

'동적인 페이지'는 데이터 처리 및 연산을 통해 화면의 내용과 데이터가 변하는 페이지이다. (백 부분이라고 봄)

데이터베이스는 웹 어플리케이션 서버의 데이터 조회, 수정, 삭제 처리 요청을 받아 연산하는 역할이다.

 

 

 

 

API(Application Programming Interface)란?

API는 기관/기업의 데이터베이스에 직접 접근하지 않고 데이터 요청을 할 수 있는 인터페이스이다.

예를 들어 서울 교통 공사의 API를 통해 DB에 직접 접근하지 않고도 원하는 데이터를 받아올 수 있다.

'인터페이스' 는 양 끝의 매체를 이어주는 매개체이다.

(ex. GUI - Graphic User Interface 는 그래픽으로 사용자에게 인터페이스를 제공한다)

(ex. CLI - Command Line Interface 는 명령어 문장으로 컴퓨터에게 명령을 내리는 인터페이스이다)

 

 

 

 

REST API란?

웹이든 앱이든 인터넷망을 사용하려면 지켜야 하는 규약(프로토콜)이 있다. 

HTTP를 지켜야 하는 것인데, 데이터 또한 지켜야 하는 형식이 있다.

 

사실 과거에는 HTTP 형식을 무시하는 경우가 있었다고 한다.

물론 잘 작동은 했지만, HTTP 창시자께서 '형식을 따라야 효율이 극대화됨'을 강조하자

사람들이 형식을 지키고자 노력하기 시작했다.

HTTP 규약을 잘 따른 API를 REST API라고 한다. 

 

REST API : HTTP 규약을 잘 따른 API

RESTful API : HTTP 규약을 매우 잘 따른 API

 

 

 

 

HTTP 형식을 지키려면?

인터넷 상에서 전달되는 모든 것들은 다 HTTP에 넣어서 보내야 한다. 

HTTP 프로토콜 템플릿은 Head와 Body로 이루어진다.

 

Head 에서는

1) 통신 상태가 어떠한지

ex. 200은 정상, 404는 요청을 찾지 못함, 500은 서버 이상

2) 응답이 어떤 형태인지

ex. html

 

Body 에서는

1) 데이터, 화면 등... 데이터의 전달 방법

2) 데이터 요청 및 그 '목적'

ex. 전체 상품 보여줘 -> 전체 상품 리스트 + '조회'

상품 등록해줘 -> 상품 등록 + '등록'

 

 

 

 

데이터를 어떻게 요청할까 - URL ?

URL은 인터넷 상에서 웹 페이지의 '위치'를 나타낸다.

그런데 서버에 데이터 요청을 보내는 역할을 수행하기도 한다.

 

예를 들면

http://localhost:8888 까지는 서버를 그냥 호출한다고 보면

http://localhost:8888/전체 상품 조회

http://localhost:8888/상품 등록

과 같이 데이터를 요청한다.

 

 

 

 

URL 실습

<REST API URL 규칙>

- 대문자 X, 소문자 O

- 언더바 X, 하이픈 O

- 마지막에 / 포함 X

- 행위/목적 포함 X

- 파일 확장자 X

- 복수형 쓰기 O

 

 

그러면 어떤 상황에서 어떤 API가 필요할까?

API 설계

 

쇼핑몰을 예를 들면,

각 쇼핑몰 페이지들은 각 API를 통해 받은 데이터를 페이지에 띄워준다.

 

쇼핑몰 메인 페이지 - 전체 상품 조회 API

상품1 상세 페이지 - 상품1 개별 조회 API

상품2 상세 페이지 - 상품2 개별 조회 API

상품 관리 페이지 - 전체 상품 조회 API

상품1 수정 페이지 - 상품1 개별 조회 API

상품1 수정 페이지의 완료 버튼 누르기 - 상품1 수정 API

 

<1> 전체 상품

http://localhost:8888/products - 전체 상품 "조회" -> "GET" 

http://localhost:8888/products - 전체 상품 "삭제" -> "DELETE"

http://localhost:8888/product - 상품 "등록" -> "POST"

 

<2> 개별 상품

http://localhost:8888/product1 - 상품1 개별 "조회" -> "GET"

http://localhost:8888/product2 - 상품2 개별 "조회" -> "GET"

http://localhost:8888/product3 - 상품3 개별 "조회" -> "GET"

아래와 같이 id를 통해 개별 상품에 접근한다.

http://localhost:8888/products/{id} - 상품 id 개별 "조회" -> "GET"

ex.

http://localhost:8888/products/1 이면 /product/{id}의 id에 1이 전달된다.

 

<3> 상품 id 개별 "수정" -> "PUT"

또한 

/products/{id}로 수정한다.

 

(상품들 중에 id 값으로 구별한다는 의미로 복수형 products 사용한다)