/date 24.08.27.
과제를 다 해 둔 덕에 내일 수강으로 되어 있는 강의를 미리 들었습니다. 부지런함 어떤데~
먼저 백엔드를 다시 돌아봅시다.
백엔드는 어떤 구조를 갖추고 있을까요?
앞서 글에서도 첨부하였던 이 사진을 다시 가져와 보았습니다.
클라이언트 = 프론트엔드? 전혀 아니다!
클라이언트 = 프론트엔드라면 네이버의 메인 화면을 우리의 컴퓨터에 갖고 있다는 소리가 됩니다. 그러니 당연히 등호가 성립할 수 없겠죠? 백엔드의 입장에서 클라이언트는 두 종류가 있습니다.
- Literally 사용자: 백엔드에게 무언가를 요청하기 전 프론트에게 요청합니다
- 프론트엔드
위의 그림에서 웹 서버, 웹 어플리케이션 서버, 데이터베이스는 말하자면 백엔드의 놀이터라고 할 수 있습니다. 웹 서버의 경우 정적 페이지에 대해 대응하고, 동적 페이지에 대한 처리는 직접 하지 않는 대신 웹 어플리케이션 서버에 전달합니다. 여기서 말하는 정적 페이지는 화면의 내용, 데이터 등의 변동이 없는 페이지를 말합니다. 개개인마다 다른 데이터를 뿌려 주는 것이 아니라, 누가 들어가도 같은 정보를 얻을 수 있어 정적이다! 라고 말하는 것이죠. 이를테면 카카오라는 기업의 연혁, 기업 소개는 제가 들어가도, 이 글을 (누가 볼진 모르겠지만) 보는 여러분이 들어가셔도 똑같은 정보를 제공합니다. 그에 반해 동적 페이지는 데이터가 계속해서 변화하고 또 추가됩니다. 개개인에 맞게 데이터가 바뀌는 개인화 페이지는 물론, 데이터의 처리 및 연산을 통해 화면의 내용과 데이터가 계속해서 변화하는 페이지를 의미합니다.
물론 요즘의 백엔드는 웹 서버 말고 웹 어플리케이션 서버와 데이터베이스 파트를 신경 쓴다고는 합니다. 동적 페이지를 신경 쓰는 것이죠.
API (feat. 인터페이스)
백엔드 개발자는 API를 만듭니다. API? 그게 도대체 뭘까요?
API는 Application Programming Interface의 약자입니다. 지하철을 타고 어딘가에 가야 할 때를 생각해 보세요. 어떤 어플을 쓰시나요? 저는 카카오맵을 쓰고 있지만 누군가는 네이버 지도, 또 누군가는 개인이 제작한 다른 어플을 사용할 것입니다. 그럼 지하철의 도착 정보에 이 많은 어플들이 전부 접근 가능하다는 말인데, 서울교통공사의 데이터베이스를 개인에게 공유하고 있는 것일까요? 당연하게도 전혀 아닙니다. 그럼 도대체 어떻게 같은 정보를 제공하는 것일까요? 이럴 때 API를 활용합니다.
사용자는 서울교통공사의 데이터를 얻고 싶습니다. 그럼 사용자와 서울교통공사 사이에 API를 두고 사용하게 되는 것입니다. 개인은 API에게 "나 이 데이터가 필요하니까 좀 제공해 줘~" 혹은 "나 이 데이터 연산 좀 해줘~"하고 요청합니다. 즉, 개인이 직접적으로 데이터에 접근해서 뭔가를 하는 것이 아니라 API라는 인터페이스를 통해 데이터를 요청하는 것입니다. 백엔드 개발자는 여기서 API와 데이터베이스를 제작하는 일을 합니다.
REST API
그럼 REST API와 그냥 API의 차이는 무엇일까요?
REST API가 없던 시절, 사람들은 이렇게 생각했습니다.
API? 그거 그냥 데이터 원하는 거 아무렇게나 던져 주면 되는 거 아님?
다시 기초로 돌아와서, 웹을 살펴봅시다. 웹은 인터넷망 속에 만들어 둔 가상의 공간입니다. 어떤 개발자이던지 상관없이 원격 통신을 해야 할 때가 많이 있습니다. (비단 개발자뿐 아니라 웹을 사용하는 많은 사람들이 원격 통신을 이용하죠?) 그런 통신을 위해서는 인터넷망의 규약을 지켜야 합니다. 인터넷을 돌아다니며 사용하고 통신하려면 지켜야 하는 규약이 바로 HTTP입니다. 이 말인즉슨, 웹 개발자는 HTTP를 지켜야 한다는 것이죠!
사실 과거에는 HTTP를 많이 지키지 않았습니다. '아, 그까짓 거, 대~충 끼워 넣어~'라는 태도로 일관했던 것이 사실입니다. 그런데 HTTP의 창시자가 냅다 등장해서 말합니다.
형식을 따르면 효율이 극대화될 텐데 너희 외않써...?
(물론 저렇게 마쭘뻡을 퐈괘하면서 말하진 않았습니다. 농담농담.) 이게 바로 REST API의 등장입니다. REST API는 HTTP 규약을 잘 따른 API입니다.
그럼 또 한 가지 궁금증이 생깁니다. REST API는 알겠고, RESTful API는 또 뭐야? 사실 아주 큰 차이는 없습니다. REST API는 앞서 말했듯 HTTP 규약을 잘 따른 API이고, RESTful API는 너무너무너무너무너무 HTTP규약을 잘 따른 API랍니다. 하하! 개발자들이 이렇게 깔깔개그를 좋아합니다.
그럼 우리는 HTTP에 무엇을 담아 보내야 할까요? 잠깐 기초부터 살펴보자면, 인터넷으로 연결된 클라이언트와 서버는 웹 프로토콜인 HTTP를 사용하여 데이터를 주고받습니다. 즉, 인터넷상에서 공유 및 전달하고 싶은 것들은 다 HTTP에 넣어서 보내야 한다는 것입니다. HTTP 프로토콜 템플릿을 간략하게 표현해 보면 아래와 같습니다.
- <HEAD>
- 통신 상태가 어떤지 알려줍니다: 200, 404, 500과 같은 코드(status code)로 알려주곤 합니다.
- 응답이 어떤 형태인지 적어줍니다: 이를테면 이 응답은 HTML 형태이다,라고 알려줍니다.
- <BODY>
- 전달해 줄 데이터 값이나 화면에 대한 정보 등등... 즉 결국 데이터의 전달은 body에 담깁니다.
- body에 '이 데이터 좀 줄래?' 하는 요청과 그 요청에 대한 목적을 담아 보냅니다.
URL
그럼 그 요청은 어떻게 말할까요? 사실 이 부분의 소제목을 보면 이미 답을 써뒀습니다. URL로 이야기하곤 합니다.
URL은 uniform resource locator의 약자로, 인터넷상에서 웹 페이지가 어디 있는지 위치를 알려 주는 주소이자, 데이터 연산 요청을 서버에 보내는 방법입니다. 예를 들어 전체 상품을 조회하고 싶을 때, 상품 등록을 하고 싶을 때, 전체 상품을 삭제하고 싶을 때 전부 같은 말을 해서는 서버가 알아듣기 힘들겠죠.
- http://localhost:8888/전체 상품 조회
- http://localhost:8888/상품 등록
- http://localhost:8888/전체 상품 삭제
이렇게 이름을 각기 다르게 지어서 불러주면 된답니다. 그럼 각각의 경우에 URL을 어떻게 지어주고, 어떤 HTTP method를 사용해야 할지 연습해 보겠습니다.
먼저 REST API URL 규칙을 몇 가지 살펴보도록 하겠습니다.
- 소문자만 사용합니다. (대문자 x)
- 언더바는 사용하지 않습니다. 대신 하이픈(-)을 사용합니다.
- URL 마지막에 슬래시(/)는 포함하지 않습니다.
- 행위, 즉 목적을 포함하지 않습니다: 메소드로 빼낼 수 있는 것(GET, POST, DELETE, PUT 등)은 URL 주소에 포함하지 않는다는 것
- 파일 확장자를 포함하지 않습니다.
- 복수형을 씁니다.
그럼 위의 규칙을 적용해서 URL을 작성하고 "메소드"를 지정해 보겠습니다.
- 상품 등록: http://localhost:8888/product + "POST"
- 전체 상품 조회: http://localhost:8888/products + "GET"
- 개별 상품 조회: http://localhost:8888/products/{id} + "GET"
- 상품 개별 수정: http://localhost:8888/products/{id} + "PUT"
- 전체 상품 삭제: http://localhost:8888/products + "DELETE"
'학습 기록 > 데브코스 웹 풀스택 4기' 카테고리의 다른 글
| 백엔드 기초: Express 기본 (1) | 2024.08.30 |
|---|---|
| 백엔드 기초: node.js, npm (1) | 2024.08.29 |
| ERD를 바탕으로 데이터베이스 생성하기 (0) | 2024.08.26 |
| ERD에 대한 이해와 데이터베이스 모델링 (0) | 2024.08.25 |
| 깃허브 페이지(github pages)로 포트폴리오 웹페이지 만들기 (0) | 2024.08.24 |