RESTful 웹 서비스 구축 - RESTful API와 마이크로 서비스: Spring Boot로 구현한 SOA 기반 아키텍쳐

RESTful 서비스와 백엔드의 역할

백엔드 개발에서는 클라이언트의 요청에 따라 데이터베이스(DB)에 저장된 리소스를 클라이언트에게 전달하는 서비스가 핵심입니다.

클라이언트는 다양한 시스템이 될 수 있습니다:

• 모바일 시스템: 안드로이드, iOS 등
• 다른 기술 스택: 파이썬, .NET 등

이처럼 서로 다른 시스템에서도 우리가 Spring Boot로 만든 백엔드 서비스를 사용할 수 있습니다. 이 경우 백엔드의 역할은 **View(화면 단)**를 개발하는 것이 아니라, 순수하게 클라이언트 요청을 처리하고 데이터(리소스)를 반환하는 것입니다.

백엔드와 View의 분리

현재는 Java 백엔드와 함께 Thymeleaf나 JSP 같은 Java 기반의 View를 만들어 화면을 구성하고 있습니다. 그러나 프로젝트가 확장되거나 다른 시스템(이기종 시스템)과 협업하게 되면, 백엔드와 프론트엔드를 분리하여 개발하는 경우가 많습니다.

• 백엔드: Spring Boot로 구축
• 프론트엔드: React, Vue.js 같은 JavaScript 프레임워크를 활용해 화면(View)을 개발

이처럼 프론트엔드와 백엔드가 분리되면, 백엔드는 클라이언트의 요청을 받아 데이터베이스에서 리소스를 가져와 API 형태로 전달하는 역할만 수행하게 됩니다.

RESTful 서비스란?

백엔드에서 클라이언트에게 데이터를 제공하는 서비스를 구축할 때, 이를 RESTful 서비스라고 많이 부릅니다. REST는 Representational State Transfer의 약자로, 웹의 자원(Resource)을 HTTP 기반으로 제공하는 설계 원칙을 말합니다.

따라서 RESTful 서비스에서는 다음과 같은 형태로 데이터를 주고받습니다:

• 클라이언트는 특정 리소스에 대한 요청을 **HTTP 메서드(GET, POST, PUT, DELETE 등)**를 사용해 보냅니다.
• 백엔드는 클라이언트의 요청에 따라 리소스를 처리하고 JSON 또는 XML과 같은 형태로 응답합니다.

이제 RESTful 서비스의 개념과 원리를 학습하면, 프론트엔드와 백엔드가 분리된 구조에서 효율적이고 확장 가능한 백엔드 서비스를 구축할 수 있습니다.

백엔드에서는, 클라이언트에게 요청이 오면 궁극적으로 DB에 있는 리소스를 클라이언트에게 내려보내주는 서비스를 하는게 가장 중요.
클라이언트는 다른 시스템일수있다. 안드로이드, IOS 등. 다른 시스템, 파이썬, .NET 계열 등. 다른 쪽 시스템에서도 우리가 Spring 쪽에서 만들어놓 백엔드쪽 서비스를 쓸수도 있다. 그러면 우리 같은 경우에는 View 를 만들 필요가 없다. 그냥 순수하게 클라이언트에게 요청이 오면은, 그 요청에 따라서 DB에 저장되어 있는 데이터를 클라이언트에게 내려보내주기만 하면 되는 것. View 를 만들 필요가 없이 말이다. 근데 지금은 우리가 백엔드도 만들고, Java로 만들고, thymeleaf, JSP도 어차피 java ERP에 종속적인 view인데 java쪽으로 해서 view를 만드는 건데, 백엔드도 만들지만 백엔드 안에서도 view 단을 만드는 걸 했다. 근데 서비스가 좀 확장되고 하다보면은 다른쪽 이기종시스템(다른 기종의 시스템)하고 같이 프로젝트를 하다보면은, view하고 백엔드가 분리해가지고 개발을 하게 될 수 있다. 그럼 Spring 단은 백엔드를 담당하면 되는 것이고, 프론트단은 리액트라던가 뷰라던가 자바스크립트 프레임워크로 요즘 많이 view 단을 만든다고 한다는데, 백엔드하고 프론트엔드가 분리해서 개발을 하고, 우리는 이제 순수하게 Spring Boot 쪽은 백엔드쪽 서비스만 하면 끝나는 것. 그러면 백엔드쪽 서비스를 한다는 건 뭐냐, 서비스를 구축해야 하는데, 구축을 하는 여럿중에 하나의 서비스 이름을 뭐라고 많이 부르냐면, REST 라는 서비스 이름을 많이 붙인다. 그래서 이제 REST가 뭔지 공부를 해보려고 한다.

---

1. REST와 REST API 개념

• 데이터와 자원
  내가 원하는 데이터나 클라이언트가 원하는 정보는 서버의 데이터베이스(DB) 에 존재한다. 이러한 데이터나 정보를 자원(resource) 이라고 부른다.
• 자원 접근과 REST API
  자원에 접근하기 위해 서버가 만든 URL의 표현을 사용하게 되는데, 이를 REST API라고 한다.
  API는 클라이언트가 서버에 요청(Request) 해서 접근할 수 있도록 만들어진 인터페이스다.
  백엔드 개발자는 이런 REST API를 통해 서버의 자원을 클라이언트가 사용할 수 있도록 제공한다.
• REST의 의미
  REST는 REpresentational State Transfer의 약자로, 자원을 URL로 표현하고 접근하는 방식이다.

---

2. 기존 개발 방식: 중앙 집중식 구조

• 지금까지의 실습 방식은 하나의 톰캣 서버 안에서 백엔드와 프론트엔드를 모두 개발하는 구조다.
• 프론트엔드는 JSP나 Thymeleaf를 사용하며, 이들은 서버 종속적이다.
  • JSP와 Thymeleaf는 톰캣 서버 내에서만 실행되기 때문에 별도의 독립된 뷰(View)로 분리할 수 없다.
• 이런 방식은 MVCS 레이어를 통해 중앙 집중식으로 관리되며, 모든 서비스가 하나의 서버에 의존한다.

---

3. 중앙 집중식 구조의 한계

• 확장성 문제: 서비스가 하나의 서버에 집중되면 서버 부하가 커질 수 있다.
• 유지 보수 문제: 서비스를 모듈화하거나 독립된 서버로 분리하기 어렵다.
• 로드 분산의 어려움: 유저 수가 증가하면 하나의 서버에 모든 서비스가 물려있어 성능이 저하될 수 있다.

---

4. 마이크로 서비스 아키텍처 (MSA) 개념

• 마이크로 서비스란?
  하나의 중앙 집중식 서비스를 독립된 서비스로 잘게 나누어 클라우드나 별도의 서버에서 실행하는 구조다.
  각 독립된 서비스는 RESTful 서비스 형태로 제공되며, 클라이언트는 이를 접근할 수 있는 URL을 사용한다.
• 마이크로 서비스 도입의 장점
  • 백엔드와 프론트엔드를 분리 개발할 수 있다.
  • 시스템 확장성과 유지 보수가 용이하다.
  • 필요에 따라 특정 서비스만 독립된 서버나 클라우드(AWS 등)로 분리할 수 있다.
• 서비스 분리와 REST API
  독립된 서비스가 만들어지면 각 서비스는 Spring Boot와 같은 프레임워크를 통해 URL을 제공한다.
  • 클라이언트는 이 URL을 이용해 REST API를 통해 데이터를 주고받는다.
  • RESTful 서비스는 주로 JSON 포맷을 사용해 데이터를 전달한다.

---

5. RESTful 서비스의 핵심

• HTTP 요청 방식
  RESTful API에서는 HTTP 프로토콜의 GET, POST, PUT, DELETE 방식을 사용하여 자원을 관리한다.
  • GET: 자원 조회
  • POST: 자원 생성
  • PUT: 자원 수정
  • DELETE: 자원 삭제
• REST의 목적
  REST를 사용하는 목적은 프론트엔드와 백엔드의 분리를 통해 시스템 확장성과 유지 보수를 더 효과적으로 수행하기 위함이다.

---

6. 프론트엔드 개발 변화

• 마이크로 서비스를 도입하면 JSP나 Thymeleaf와 같은 서버 종속적 뷰 대신, 독립된 프론트엔드를 개발할 수 있다.
• 프론트엔드 기술 예시:
  • React.js
  • Next.js
  • 자바스크립트 기반 프레임워크를 이용해 뷰(View)를 구축할 수 있다.
• 이러한 프론트엔드는 백엔드의 REST API를 호출해 데이터를 가져와 화면을 구성한다.

---

이와 같이, 마이크로 서비스 아키텍처와 RESTful API를 사용하면 서비스의 독립성, 확장성, 그리고 유지 보수성을 크게 향상시킬 수 있다.

 

내가 원하는 데이터, 클라이언트가 원하는 정보는 서버에 있는 DB에 들어있다. 그런 데이터, 정보가 모두 자원이라고 부를 수 있다. 그런 자원에 접근을 하기 위해서 서버가 만들어놓은 하나의 URL의 표현, 그걸 조금 더 쉽게 말해서 REST API 라고 부른다. API 이기 때문에, 우리가 만들어놓으면(API의 형태로 표현을 해놓으면) 다른 클라이언트는 이 API(표현된 URL)를 요청해서(접근해서) 쓰는 것. 우리는 서버단쪽이니까 쓰는 쪽이 아니라서 백엔드 쪽 개념으로 바라보겠다. REpresentational State Transfer(REST)

지금까지 공부하면서 실습으로 개발을 한 방식은, 하나의 서버, 톰캣 서버 안에 백엔드쪽도 있으면서 프론트엔드도 만들고 있는 것. 어차피 프론트도 JSP나 Thymeleaf로 구축을 한다. JSP나 Thymeleaf 엔진을 별도로 구동시킬 수는 없다. 서버, 톰캣서버 안에서 구동을 해야 되기 때문에, 우리가 만들고 있는 뷰 자체가 서버에 종속적이다. 이 뷰를 별도로 밖으로 빼서 만들 수 있는 성질의 것이 아니다. 서버, 톰캣 서버 안에 내장해서 만드는, 종속적으로 만드는 뷰를 하고 있고, JSP나 Thymeleaf 의 뷰는 클라이언트 요청이 오면, 백엔드 쪽에서 서비스를 하고 있는데, MVCS 라는 레이어를 이용해가지고 클라이언트 요청이 오면 서비스를 하고 있는데, 하나 하나의 서비스, 이 모든 서비스가 톰캣 서버 안에 중앙 집중식으로 만들어가지고 관리를 하고 있는데, 이런 서비스 하나 하나를 독립시켜가지고 모듈을 시켜가지고 별도로 이 서비스를 다른 서버에서 이 서비스들을 구동을 하고 있는 그런 형식은 아니다. 하나의 서버 안에서, 즉 중앙 집중식 형식의 서비스를 하고 있다는 것. 백엔드 쪽 서비스 부분과 프론트의 뷰를 분리를 해서 개발을 하는게 아니라 하나의 서버 안에서 지금 개발을 하고 있고, 또, 이런 서비시들을 분리개발하는게 아니라 하나의 서버 안에서 중앙 집중식으로 구현을 하고 있는 것. 모듈화를 시켜가지고 잘게 쪼개가지고 서버를 좀 확장시키거나 하기에는 무리가 있다는 것. 그리고 이 서버에 많은 유저가 달라붙었을 경우에는 이 각각의 서비스들이 하나의 서버에 물려있다보니까 부하라던가 로드가 많이 걸릴 수도 있다. 그래서 이런 하나 하나의 서비스를 잘게 분해해서 밖으로 빼가지고 별도의 어떤 서비스로 만들어가지고 이런 별도의 서비스를 클라이언트가, 내가 원하면 중앙 집중식으로 서비스를 만드는게 아니라, 이런 서비스를 별도로 클라우드라던가 AWS 같은 독립형 서비스로 뺄 수가 있다는 것. 굳이 다 빼는게 아니라 꼭 필요한 것들은 독립형 서버에다가 만들어가지고 빼낼 수 있다. 그러면 중앙 집중식이 아니다. 별도의 서버, 서버 하나에다가 모든 서비스를 다 뺄 수도 있지만, 서비스 2개씩 그룹을 묶어가지고 여러 서버에다가 뺄 수도 있고, 구축 하는 방법에 따라서 달라질 것. 그래서 중앙 집중식 서비스를 모듈화 시켜가지고 잘게 잘게 잘게 쪼개가지고 만들어지는 서비스들을 우리가 마이크로 서비스 라는 용어로 부른다. 마이크로 서비스는, 중앙 집중식으로 구현된 서비스들을 별도의 독립형 서비스, 독립형 서비스로 구동을 시키려면 뭔가 클라우드라던가 AWS라던가 뭔가 서버에다가 이런 서비스들을 만들어가지고 넣어놓아야겠다. 이런 서비스들이 하나씩 하나씩 만들어지면, 결국에는, 어떤 뷰에서, 어떤 클라이언트가 이런 서비스를 사용을 해야 하는데, 그러면 사용을 하기 위해서는 이런 서비스를 접근할 수 있는 URL 을 만들어놓아야 할 것이다. 별도의 서버, 또는 별도의 서버들이, 이런 URL을 만들어가지고 서비스를 해주는, 이런 서비스를 RESTful 서비스라고 한다라고 보면 되겠다. 마이크로 서비스가 되려면 기본적으로 REST 서비스가 되어야한다. REST는, 서비스들을 밖으로, 클라우드라던가 이런 독립형 서비스로 빼서, 이런 서비스들이 DB와 연동이 되어 있을 것인데, 클라이언트가 DB에 있는 자원을 얻어가고 싶다면 이 클라이언트는 REST API (특정 서비스)를 쓸려면 자원을 접근하는 URL을 알아야 하는데, 그 URL은 서버에서 만들어주는 것, 어떻게? Spring Boot 로 서비스단을 만들어가지고 URL을 제공해주게 되면은 다른쪽 클라이언트는 이 URL을 이용해서 특정 서비스를 사용할것. 이 서비스는 DB에 있는 내용을 상호작용을 해가지고 서로 주고 받고 할 수 있는 것. 그래서, 마이크로 서비스 라는 개념을 도입을 한다라고 한다면, 백엔드와 프론트엔드가 분리 개발할 수 있다. 별도로 구축된 서비스들, REST API들이 백엔드가 되는 것.  지금은 프론트가 JSP 라던가 Thymeleaf 인데, 얘네들을 돌릴려면 어차피 톰캣서버로 돌려야 한다. 그래서 마이크로 서비스 쪽으로, 서비스단이 빠져나가게 되면은 굳이 뷰는 JSP 라던가 Thymeleaf 로 구현을 할 필요가 없다. 그러면 뷰는 뭐로 구현을 하면 되는가? Node JS의 React.js 라던가 Next.js, 자바스크립트 프레임워크 기반의 엔진을 이용한 뷰를 만들 수가 있는 것. 그래서 이런 식의 서비스를 만들게 되면은, 클라이언트하고 서버 간의 데이터 전송 포맷은 JSON이나 XML로. 근데 일반적으로 JSON 으로 데이터를 주고 받고 한다. RESTful API에서 또 진짜 중요한 부분은, 이 클라이언트가 이 서버에 URL에 접근할 때, URL의 요청 방식이 있는데, 클라이언트는 서버에 요청을 할 때 요청 방식이 있는데, HTTP 프로토콜에서 GET/POST/PUT/DELETE 방식이 있을 것인데, REST 라는 표현법은 HTTP 요청, 클라이언트의 요청 방식과 자원이 있는 URL 정보를 같이 더해서 하나의 REST의 URL이 만들어지는 것. 그래서, REST를 쓰는 목적 자체는 프론트 엔드와 백엔드 구성 요소들 간의 어떤 문제들을 더 효과적으로 분리. 시스템 확장성, 유지 보수 등의 이점이 있다.

---

1. REST API와 REST 서비스의 개념

• 우리가 Spring Boot로 만드는 것은 REST API와 이를 통해 제공되는 RESTful 서비스이다.
• REST 서비스를 만든다는 것은 DB의 자원에 접근할 수 있는 URL을 만들어주는 것을 의미한다.
• 이러한 URL은 클라이언트가 서버에 있는 데이터를 가져갈 수 있도록 제공되며, 일관성 있게 설계되어야 한다.
• REST API란:
  • HTTP 요청 방식 + 경로 정보(URL) 를 조합해 만든 고유한 주소
  • 이 URL은 자원의 엔드포인트(endpoint) 를 의미한다.

---

2. HTTP 요청 방식과 REST API

REST API에서 클라이언트는 자원을 요청할 때 HTTP Method(요청 방식) 를 사용한다.
HTTP 요청 방식과 함께 일관된 URL이 있어야 어떤 작업을 할지 명확히 구분할 수 있다.

HTTP Method	동작	설명
GET	조회 (Select)	서버에서 데이터를 가져온다.
POST	생성 (Insert)	데이터를 서버에 저장한다.
PUT	수정 (Update)	기존 데이터를 수정한다.
DELETE	삭제 (Delete)	데이터를 삭제한다.

• 예시
  클라이언트가 products/2라는 URL에 접근하려고 할 때, HTTP 요청 방식이 없으면 무엇을 하려는지 알 수 없다.
  • GET: products/2 → 2번 제품 조회
  • DELETE: products/2 → 2번 제품 삭제

따라서 요청 방식 (GET, POST, PUT, DELETE) 과 URL이 합쳐져서 REST API 주소가 만들어진다.

---

3. REST API의 역할

• REST API 주소는 고유한 주소이며 자원의 엔드포인트를 의미한다.
• 클라이언트는 이 엔드포인트(URL) 를 통해 서버에 자원을 요청하고 데이터를 주고받는다.
• 데이터 전송 형식:
  • 일반적으로 JSON 형식을 사용하여 클라이언트와 서버 간 데이터를 주고받는다.
  • 예:
    • GET 요청 → JSON 형태로 데이터를 전달받음
    • POST 요청 → JSON 형태로 데이터를 서버에 보냄

---

4. RESTful 서비스의 정의

• REST API를 이용해 자원을 제공하고 관리하는 서비스를 RESTful 서비스라고 한다.
• 우리는 개발자 입장에서 REST API를 설계하고, 클라이언트의 요청에 따라 서버가 JSON 형태로 데이터를 내려주면 된다.

---

핵심 요약

• REST API는 HTTP 요청 방식과 경로(URL) 를 조합해 자원에 접근하는 고유한 주소이다.
• REST API를 통해 제공되는 서비스를 RESTful 서비스라고 한다.
• 클라이언트와 서버는 주로 JSON 형식으로 데이터를 주고받는다.
• 개발자는 Spring Boot를 통해 REST API를 설계하고, 클라이언트의 요청에 따라 데이터를 처리해 주면 된다.

우리는 이제 Spring Boot로 뭘 만드는 걸까? REST API, REST 서비스들 만드는 것. REST 서비스를 만든다는 뜻은, 자원을 접근하는 URL을 각각 만들어준다는 걸 의미, DB에 있는 데이터를 클라이언트가 가져가도록 하기 위해서 우리가 각각의 서비스를 만들어주면 되는데, 그 서비스가 바로, URL을 만들어주면 되겠다. 그 URL은 주소인데, 그 주소는 중구난방이 아니라 일관성있게 만들어줘야 한다. 서버는 클라이언트가 자원을 접근할 수 있도록 일관성있게 URL을 만든다. 어쨌든, 그 만든 URL을 REST API 라고 한다. 그리고 요청을 구분하기 위해서 HTTP Method (요청방식) 를 사용한다.그래서 [REST API : 요청방식 + 경로 정보를 담아낸 URL] (* 고유한 주소 - 자원의 엔드 포인트)
GET (select) - 가져오는 것. (그러면 JSON 형태로 값을 전달해준다)
POST (insert) - 저장하는 것. (저장할 때도 그럼 JSON 형태로 값을 전달받는다, 즉 클라이언트와 서버는 JSON으로 데이터를 주고받는다고 생각하면 된다.)
PUT (update) - 업데이트 하는 것. (업데이트를 한다는 건 데이터를 수정한다는 건데, 수정된 데이터를 넘기면 된다.)
DELETE (delete) - 삭제하는 것.
여기서, 요청 방식을 알지 못 하면, GET, POST, PUT, DELETE 가 함께 있는게 아니라면, 만약 products/2 라고 해서 2번 제품에 대해서 뭔가를 하고 싶은데, GET인지, DELETE 인지 알 수가 없기 때문에 요청 방식도 함께 있어야 한다는 것.
 그래서, 요청방식과 URL이 합쳐져서 REST API 주소가 만들어진다는 것이 상당히 중요하다. 이 REST API 주소는 고유한 주소이다. 다르게 말하면 자원의 엔드포인트다. 자원을 핸들링하기 위해서는 자원의 주소를 알아야 하는데, 표현된 주소를 REST API라고 하는데, 이런 REST API를 가지고 서비스를 해주는 서비스를 RESTful 서비스라고 부르면 되겠다. 우리는 개발자 입장이니까, 이런한 REST API 주소를 만들어가지고 클라이언트가 요청이 오게 되면은 요청에 따라서 데이터를 JSON으로 내려보내주게하면 된다. 

---

1. RestController와 RESTful API

• Spring Boot는 RestController라는 기능을 제공한다.
  • RestController: 클라이언트의 요청이 오면 데이터를 처리하고 JSON 데이터 포맷으로 응답을 내려주는 컨트롤러다.
• RESTful API의 백엔드 구조:
  • 컨트롤러 - 서비스 - 모델 패턴으로 설계한다.
  • 이 구조는 뷰(View) 없이 서비스만 제공하는 서버를 의미한다.

---

2. 서비스 지향 아키텍처 (SOA)

• SOA (Service-Oriented Architecture) 란?
  • 뷰(View)를 가지지 않고 클라이언트 요청에 순수하게 서비스만 제공하는 아키텍처다.
  • RESTful API를 기반으로 서비스만 전문적으로 제공하는 구조가 SOA에 해당한다.
  • 마이크로 서비스 아키텍처(MSA)도 SOA의 일종이다.

---

3. 백엔드와 프론트엔드의 분리

• RESTful API를 백엔드에서 만들어놓으면, REST API 주소는 오픈되어 프론트엔드가 이를 통해 데이터를 요청하고 응답받는다.
• 데이터 전송 형식: JSON 또는 XML
• 통신 방식:
  • 주로 Ajax 통신 (비동기 전송) 방식을 사용한다.
  • Ajax는 자바스크립트 기반으로 클라이언트와 백엔드 간 데이터를 비동기적으로 주고받게 한다.

---

4. 백엔드와 프론트엔드 분리 개발의 목적

1. 모듈화
   • 프론트엔드와 백엔드를 분리하면 유지 보수와 업데이트가 용이하다.
   • 각 부분을 독립적으로 개발 및 수정할 수 있다.
2. 확장성
   • 백엔드 서비스는 수요에 따라 독립적으로 확장할 수 있다.
   • 서비스가 커지면 특정 기능만 확장하는 것도 가능하다.
3. 응답성 개선
   • 클라이언트 측 렌더링과 비동기 통신은 보다 빠르고 원활한 사용자 경험(UX)을 제공한다.

---

5. RESTful API 기반 접근 방식

• RESTful API를 기반으로 프론트엔드와 백엔드를 분리하는 접근 방식은 모듈화와 확장성을 강조하는 최신 웹 개발 원칙이다.
• 이 방식을 통해 시스템은 더 유연하고 유지보수가 쉬운 구조로 발전할 수 있다.

---

핵심 요약

• RestController는 클라이언트 요청을 처리해 JSON 형태로 데이터를 반환한다.
• SOA는 뷰 없이 서비스만 전문적으로 제공하는 구조로, 마이크로 서비스 아키텍처가 이에 포함된다.
• Ajax 비동기 통신을 사용하면 프론트엔드와 백엔드 간 원활한 데이터 교환이 가능하다.
• 프론트엔드와 백엔드의 분리 개발은 모듈화, 확장성, 그리고 응답성 개선에 큰 이점을 제공한다.

Spring Boot 는 RestController라는 걸 제공해준다. RestController는 클라이언트가 요청이 오면은 데이터를 처리해서 JSON 데이터 포맷으로 데이터를 내려보내주는 그런 컨트롤러. 
RESTful API의 백엔드 쪽은 컨트롤러 서비스 모델(데이터 영역)  - 컨트롤러 서비스 모델 패턴으로 만들어주면 된다. view는 없고, 서비스만 전문으로 해주는 그런 서버가 되겠다. 그래서 그걸 서비스 지향 아키텍쳐라고 해서, SOA 라고 한다. 마이크로 서비스 이런 것들이 SOA 라고 보면 되겠다. view 를 가지고 있지 않고 클라이언트의 요청이 오면은 순수하게 서비스만 전문으로 하는 그러한 APIs를 가지고 있는 서비스를 서비스 지향 아키텍쳐라고 부른다.
이렇게 백엔드를 만들어놓고 나면은, REST API 주소는 다 오픈이 되어 있을 것인데, 그 주소를 프론트가 이용해가지고 요청을 하면 그 정보를 내려보내주면 되겠다. JSON이나 XML로 데이터를 상호 주고 받으면 된다. 이러한 통신을 Ajax 통신, 비동기 전송으로 많이 통신을 한다. 백엔드 쪽과 프론트엔드의 통신 방법은 자바스크립트 기반이라면은 Ajax, 비동기 전송으로 많이 통신을 한다. 이렇게 백엔드와 프론트엔드를 분리 개발하는 목적은?
- 모듈화를 시킬 수 있다: 프론트와 백엔드 문제를 분리하면 유지 관리 및 업데이트가 더 쉬워진다.
- 확장성이 좋아진다: 백엔드 서비스는 수요에 따라 독립적으로 확장될 수 있다.
- 응답성이 좋아진다: 클라이언트 측 렌더링 및 비동신 통신은 보다 원활한 사용자 경험을 제공한다.
(RESTful API 기반 프론트 엔드 접근 방식 - 모듈화, 확장성을 강조하는 최신 웹 개발 원칙)

---