Restful API

 

이번엔 Restful API 즉, Rest API에 대해서 알아보려고 한다.

 

정의

• 애플리케이션의 데이터와 기능을 외부에 공개하는 방법으로, 사용자는 API로 제공되는 구현 방법에 상관없이 해당 기능을 사용할 수 있다.
• 원하는 자원을 HTTP URI로 표현하고 리소스의 대한 행위를 HTTP Method로 표현한다.
• 설계는 아키텍쳐 스타일을 의미하며 표준이 아니고 유연하게 사용가능합니다.

 

즉, Rest API란 특정 규칙이 정해져있고 그걸 안지킬 시 기능을 사용못하고 그런 것은 아닙니다. 다만 이러한 규칙을 지켜 애플리케이션의 자원을 요청하고 응답하자는 일종의 규칙이자 아키텍쳐 스타일을 의미합니다.

 

 

특징

• Server - Cleint 구조 : 자원이 있는 쪽 Server, 자원을 요청하는 쪽은 Cleint로, 누구나 서버, 클라이언트가 될 수 있습니다.
• Stateless : 서버는 클라이언트의 정보를 전혀 모릅니다. 즉, 서버는 어떤 요청을 하고 어떤 자원을 원하는지만 알 수 있습니다.
• Cacheable : HTTP 프로토콜을 사용하기 때문에 HTTP의 캐싱 기능을 적용해 대량의 요청을 효율적으로 관리합니다. 즉, 여러 요청에 대해 캐시가 있기때문에 모든 요청을 서버에 요청을 하지는 않습니다.
• 계층화 : 서버는 다중 계층으로 구성될 수 있고 이와 상관없이 클라이언트는 서버에 API요청 가능하다. 서버는 로드 밸런싱, 보안 요소, 캐시 등 여러 층으로 이루어져 있을 수 있습니다. 하지만 클라이언트는 상관없습니다.
• 인터페이스 일관성 : 일정한 인터페이스를 제공하기에 HTTP 프로토콜을 따르는 모든 플랫폼에서 사용가능하다.
• Code on Demand : 서버는 요청에 대한 응답으로 코드 또는 스크립트(로직)을 전달하여 클라이언트의 기능을 확장시킬 수 있습니다. 하지만 이는 선택적입니다.

 

 

장점

• HTTP통신을 사용하는 모든 플랫폼에서 사용가능 합니다.
• 항상 서버와 클라인트가 존재하고 이들의 역할을 명확히 구별가능합니다.
• 여러 서비스 설계에서 생길 수 있는 문제를 최소화합니다.
• Rest 기반으로 시스템을 분산하여 확장성과 재사용성을 높입니다. 

 

 

설계 규칙, 아키텍쳐 스타일

• URI를 통해서만 원하는 자원을 표현한다.
• URI는 소문자를 통해서만 작성가능하고 언더바(_), 확장자는 사용불가능하다.
• 원하는 자원의 이름이 길어질 시 하이픈(-)을 이용함을 권장한다.
• URL에는 동사가 들어가지 않는다.
• 원하는 작업(CRUD)은 HTTP Method를 통해서만 표현하고 URI로 표현해서는 안된다.
• 자원은 다중 표현이 가능하다. 즉, 클라이언트에 xml, html, text, json 등 여러가지 형태의 데이터를 보낼 수 있다.

 

(+) URL vs URI

URI는 URL보다 좀 더 큰 개념으로 URI는 식별자, URL은 식별자 + 자원의 위치까지 표현가능합니다.

URI - http://www.test.com

URL -http://www.test.com/recources 

 

 

 

이용 객체

- 가벼운 인터넷 제공 업체, Google, Naver등은 Rest를 이용하지만 금융감독원처럼 보안 등의 제약이 많은 경우는 Web Service 아키텍쳐를 통해 통신합니다.

 

 

사용 예시

한번, 기사를 다루고 있는 한 뉴스사이트에 요청을 보낸다고 가정해보겠습니다.

 

 

POST Method 사용한 경우

article -> 새로운 article 생성

article/1234 -> 오류

 

GET Method 사용한 경우

article -> 기사 목록

article/1234 -> 특정 기사 보기

 

PUT Method 사용한 경우

article -> 모든 기사들 업데이트 

article/1234 -> 해당 번호를 갖는 기사 업데이트, 없으면 오류

 

DELETE Method 사용한 경우

article -> 모든 기사 삭제

article/1234 -> 특정 기사 삭제

 

 

 

Rest 성숙도

성숙도를 평가하는 레벨에는 0부터 3까지 총 4단계가 존재합니다.

위의 설명한 규칙들을 모두 준수하고 잘 활용한다면 레벨2로 볼 수 있습니다.

만약 서버로부터 클라이언트로 가는 응답에 하이퍼미디어 컨트롤을 포함하고 있어 클라이언트가 할 다음 액션을 안내한다면 레벨 3단계로 볼 수 있습니다. 레벨 0과 1은 고려하지 않겠습니다.

 

 

 

 

 

Rest API with Spring

원리 : 스프링 Main에 있는 @SpringBootApplication이 HTTP의 JSON을 객체 등 필요한 형태로 매핑해줍니다.

스프링에서는 Rest API를 사용하기위한 다양한 애너테이션을 지원합니다.

 

Post Method로 서버에 요청

- @PostMapping 으로 매핑

- @RequestBody로 요청에 있는 내용 읽음.

 

Get Method로 서버에 요청

- @GetMapping 으로 매핑

- @PathVariable로 URL에 포함된 자원 읽음 -> web/자원

- @RequestParam으로 URL에 포함된 자원을 읽는다. -> web?자원="abc"

 

Put Method로 서버에 요청

- @PutMapping 으로 매핑

- @PathVariable로 URL에 포함된 자원 읽음 -> web/자원

- @RequestParam으로 URL에 포함된 자원을 읽는다. -> web?자원="abc"

- @RequestBody로 요청에 있는 내용 읽음.

 

Delete Method로 서버에 요청

- @DeleteMapping 으로 매핑

- @PathVariable로 URL에 포함된 자원 읽음 -> web/자원

- @RequestParam으로 URL에 포함된 자원을 읽는다. -> web?자원="abc"

 

 

 

(+)

@RequestHeader("확인하고자하는 내용") : HTTP의 헤더를 가져옴.