백엔드 개발자의 역할
백엔드 개발자는 API(Application Programming Interface)를 개발하여 서로 다른 소프트웨어 혹은 시스템 간의 연결을 가능하게 한다.
예를 들어, 지하철 도착 정보 어플을 만들고자 할 때, 개인이 직접적으로 서울 교통 공사의 데이터베이스에 접근하는 것은 보안상 허용되지 않는다.😂 대신, 백엔드 개발자는 안전하게 접근할 수 있는 API를 개발한다.
- API의 역할
API는 애플리케이션과 서울 교통 공사의 데이터베이스 사이의 중재가 역할을 한다. 개발자는 API를 통해 지하철 도착 시간, 역 정보 등의 데이터 요청을 할 수 있다.
(단순히 데이터를 "줘"라는 요청 뿐만 아니라, 필요에 따라 데이터 연산이나 처리를 요구하는 복잡한 작업을 수행할 수 있다.) - 데이터 요청
애플리케이션 사용자가 지하철 도착 정보를 요청할 때, API는 이 요청을 서울 교통 공사의 데이터베이스로 전달하고, 필요한 데이터를 검색하여 애플리케이션으로 다시 전송한다.
Interface란?
두 개체 혹은 시스템 간의 중재자/매개체 역할을 한다. 사용자 인터페이스(UI)는 아래와 같은 두 가지 주요 형태가 있다.
- GUI(Graphic User Interface): 그래픽을 통해 사용자가 시스템과 상호작용하는 방식
- CLI(Command Line Interface): 텍스트 명령어를 통해 시스템과 상호작용하는 방식
REST API 정의
REST API(Representational State Transfer API)는 웹 표준을 기반으로 개발된 API이다. HTTP 프로토콜의 원칙을 준수하면서 웹에서의 데이터 교환을 원활하게 한다. 각 리소스는 URL로 고유하게 식별되며, 표준 HTTP 메소드를 사용하여 리소스 상태를 조회하거나 업데이트한다.
강사님이 이해하기 쉽게 비유를 해주셔서 가려운 곳을 긁은 기분이었다..
데이터 "아무렇게나" 주고 받으면 되는 건가? 아니!
웹(=인터넷 망 속 가상 공간) 개발자는 인터넷을 돌아다니기 위한 규약을 지켜야만 한다. = HTTP를 지켜야 한다.
과거에는 HTTP 형식을 무시하고 비효율적으로 데이터를 교환했었지만, 2000년대 초반 HTTP 창시자들이 이 형식 따를 때 효율이 극대화된다고 강조한 이후, 이 규칙을 엄격히 지키기 시작했다.
- REST API : HTTP 규약을 따르면서 데이터 교환을 효율적으로 수행할 수 있도록 설계된 API
- RESTful API: HTTP 규약을 매우 철저히 준수하여 설계된 API, 통신의 표준화를 한층 더 높여준다.
따라서 인터넷 상에서 원활한 데이터 공유와 전달을 위해 모든 데이터는 HTTP 프로토콜의 규약에 따라 안전하게 전송되어야 한다.
+ REST API 특징
- Stateless: 각 요청이 독립적으로 처리된다. 서버는 클라이언트의 상태를 저장하지 않는다.
- Uniform Interface: 통일된 인터페이스를 통해 시스템 내부 구현을 숨기고, 각 요소가 서로 독립적으로 진화할 수 있게 한다.
- Cacheable: 응답은 캐시 가능성이 명시되어야 하며, 적절한 관리를 통해 성능을 향상시킬 수 있다.
좋은 REST API 설계 규칙
- 소문자 사용: 대소문자 구별하기 때문에 일관성 유지하기 위해 소문자만 사용
- 하이픈(-) 사용: 가독성을 높이기 위해 언더바(_) 대신 하이픈(-) 사용
- 끝에 슬래시(/) 포함하지 않기: URI 끝에 슬래시(/) 포함하지 않음
- 행위를 포함하지 않음: 리소스에 대한 행위를 포함하지 않음. 행위는 HTTP 메소드(GET, POST, PUT, DELETE)로 표현함
- 파일 확장자 포함하지 않기: 리소스 표현은 HTTP 헤더를 통해 관리함
- 복수형 명사 사용: 리소스는 복수형 명사를 사용하여 표현함
URL+method 연습을 한 번 해보자!
- 상품 등록: POST /products
- 전체 상품 조회: GET /products
- 상품 개별 조회: GET /products/{id}
- 상품 수정: PUT /products/{id}
- 전체 상품 삭제: DELETE /products
ex. /product/1 ⇒ id=1인 데이터를 수정함
cf. 복수형으로 표현하면 좋은 이유
- 상품들 중에서 id값을 가지는 개별 데이터라는 의미를 이해할 수 있음
- 통일감 줄 수 있음
위와 같이 연습해본 것을 “API 설계”라고 부른다! 이제 나도 API 설계 해봤다!라고 말할 수 있다.
이러한 설계 원칙과 구조를 따름으로써 더욱 명확하고 효율적으로 데이터를 처리하고 사용자에게 서비스를 제공할 수 있다.
