반응형
0. API란?
- API는 Application Programming Interface의 약쟈로, 한 프로그램에서 다른 프로그램으로 데이터를 주고 받기 위한 방법입니다. (방법이란, 결국 코드임!)
- 웹서버에 어떤 상품의 정보를 보여주는 코드가 있다고 가정했을 때, 유저가 어떻게 이 코드를 실행시킬 수 있을까요? 바로 API를 통해서 실행시킬 수 있습니다.
위의 코드가 상품(product)의 정보를 데이터베이스에서 꺼내서 보여주는 코드라고 가정해봅시다. 유저가 이 코드를 실행시키기 위해서는 API 코드가 필요합니다.
app.get()
부분이 API 코드에 해당하는 부분입니다. 사용자가 https://example/detail/:10을 요청하면 상품을 정보를 보여주는 코드가 실행되는 것이지요!
즉, API는 주문을 할 수 있게 해주는 메뉴판에 해당한다고 생각하면 됩니다. 메뉴판없이 주문을 할 수는 없습니다. API로 요청을 하는 것이 메뉴판에 있는 메뉴 안에서 주문을 하는 것에 해당하고 요청을 내려받는 것이 음식이 서빙받는 것에 해당한다고 볼 수 있습니다.
모든 프로그램은 API를 가질 수 있습니다. 예를 들어 운영체제인 Windows도 프로그램입니다. 따라서 Windows API를 쓰면 윈도우 운영체제 기능들을 사용할 수 있습니다. 데이터베이스 관리프로그램 API를 사용하면 데이터베이스의 입출력 등의 기능들을 사용할 수 있겠지요.
- API를 개발할 때는 다음 3가지가 필요합니다.
- 어떤 요청을 할 것인가?(method): 데이터를 달라고 할것인지(GET), 데이터를 보낼 것인지(POST)를 명시해야 합니다.
- 어떤 데이터를 요청할 것인가?(endpoint)
- 부가적으로 실어보낼 정보(query parameter)
1. REST API란?
REST API는 API를 잘 만들 수 있는 방법 중 하나입니다. API의 작동 방식은 SOAP API, RPC API, Websocket API 등이 있는데, REST API는 현재 웹에서 가장 많이 사용되는 API입니다.
- REST API는 Representational State Transfer의 약자로, 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 방법을 의미합니다. 즉, URI를 통해서 자원을 지정하고, HTTP 메서드를 통해 해당 자원에 대해 어떤 행위를 할 것인지 표현합니다.
예를 들어 사용자를 CRUD하는 API를 만든다고 하면 아래와 같이 나타낼 수 있습니다.
HTTP method | URI | |
CREATE | POST | /user |
READ | GET | /user/1 |
UPDATE | PUT | /user/1 |
DELETE | DELETE | /user/1 |
- Rest의 개념을 만든, Roy T.Fielding은 이렇게 말했습니다. "HTTP에서 정의한 방식대로만 잘 쓴다면 REST는 딱히 할 말이 없다" Fielding이 말하는 REST API란, REST 아키텍쳐 스타일에 부합하는 API입니다. 이는 다음 6가지 항목으로 말할 수 있습니다.
- Client-server: 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 합니다.
- Stateless: 요청에 대해서 클라이언트의 상태를 서버를 저장하지 않습니다.
"치즈버거 주세요." "그리고 콜라 추가해주세요."(X)
"치즈버거와 콜라 주세요." (O) - Cache: 클라이언트는 응답을 Cache(임시저장)할 수 있어야 합니다. 클라이언트가 Cache를 통해서 응답을 재사용할 수 있어야 하고, 이를 통해서 서버의 부하를 낮출 수 있습니다.
- Uniform Interface(계층의 일관성): 인터페이스의 일관성을 지키고, 아키텍쳐를 단순화시켜 작은 단위로 분리하여 클라이언트-서버가 독립적으로 개선될 수 있어야 합니다. 인터페이스가 일관성을 갖는지는 다음 4가지로 판단할 수 있습니다.
- 자원의 식별: 웹 기반의 REST에서는 리소스에 접근할 때, URI를 사용합니다.
여기서 자원이란, 이름을 지닐 수 있는 모든 정보(개념적인 대상)을 말합니다. (문서, 이미지, 사람 등) Fielding은 자원은 객체이므로 상태가 변화 가능하므로 변하지 않는 식별자가 필요하다고 말합니다. 이 때, 그 식별자가 URI가 됩니다. 따라서 URI를 통해서 자원을 식별합니다. 예를 들어, /user/1이라는 URI로 user 데이터베이스에서 id가 1인 사용자를 식별할 수 있는 것이지요. - 표현(메시지)을 통한 자원의 조작: 리소스 조작을 위해서 데이터 전체를 전달하지 않고, 이를 메시지로 전달합니다.
웹에서 데이터를 전달하는 방식은 HTML, XM, JSON, TEXT 등 다양합니다. 따라서 하나의 자원은 다양한 방식으로 표현이 가능합니다. 이때 데이터가 어떤 타입인지 알려주기 위해 HTTP 헤더에 content-type을 통해서 데이터 타입을 지정해줍니다. - 자기 서술적 메시지: 클라이언트와 서버를 오가는 메시지는 스스로에 대해 설명해야 합니다. 즉, 요청하는 데이터가 어떻게 처리되어져야하는지 충분한 데이터를 포현할 수 있어야 합니다.
HTTP 기반의 REST에서는 HTTP 메서드와 헤더 정보, 그리고 URI에 포함되는 정보로 표현할 수 있습니다.
ex)
GET: https://foo.co.kr/user/100 (사용자 정보 요청)
POST: https://foo.co.kr/user (사용자 정보 생성)
PUT: https://foo.co.kr/user (사용자 정보 생성 및 수정)
DELETE: https://foo.co.kr/user/100 (사용자 정보 삭제) - HATEOAS(Hypermedia as the Engine of Application State): 하이퍼미디어를 통한 앱 상태 변경이 이루어져야 합니다. 일반적으로 프론트엔드와 백엔드 사이에서는 json 형태로 데이터가 오고가고, 프론트에서는 json을 html로 구성하며 html에서 앱 상태 변경이 가능합니다. 하지만 이때 REST API를 개발하려면 json에 URI를 포함해서 클라이언트에 전송해야 HATEOAS에 위배되지 않습니다. 즉, REST API를 개발할 때 단순히 클라이언트 요청에 대한 데이터만 응답해주는 것이 아니라 관련된 리소스에 대한 link 정보까지 같이 포함되어져야 합니다.
- 자원의 식별: 웹 기반의 REST에서는 리소스에 접근할 때, URI를 사용합니다.
- Layered System: 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 통해 서버의 확장을 이룰 수 있어야 합니다.
- Code-On-Demand: 자바스크립트 등 특정한 기능을 서버로부터 클라이언트가 전달받아 코드를 실행할 수 있어야 합니다. (최근 현업에서는 지키지 않는 곳이 대부분입니다.)
반응형
'Java > Spring' 카테고리의 다른 글
[Spring Boot] API 개발 - response 내려주기 (0) | 2023.01.23 |
---|---|
[Spring Boot] API 개발 (1) | 2023.01.23 |
[Spring MVC] Presentation Tier 구현 (0) | 2023.01.12 |
[Spring MVC] Business Tier 구현 (0) | 2023.01.11 |
[Spring MVC] Persistence Tier CRUD 구현 (0) | 2023.01.11 |
댓글