'Rest API' 란?
REST API를 적용하기 전에 'REST API' 가 무엇인지에 대해 알아보고자 한다.
먼저 REST란 (Representational State Transfer)의 줄임말로 아파치 HTTP 서버 프로젝트의 공동설립자인 로이 필딩(Roy Fielding)이란 사람이 2000년에 발표한 논문에서 처음 소개되었다.
웹 시스템을 외부에서 이용하기 위한 프로그램의 요청 규칙의 한 종류로써 REST라고 부른다. REST 그 자체는 적용범위가 넓고 유동적인 모델이지만, 일반적으로는 REST의 개념을 Web API에 적용한 것을 RESTful API라고 부른다.
RESTful API에서는 url/uri의 모든 리소스를 한 번에 식별하고 세션관리와 상태관리 등을 하지 않으며(Stateless), 같은 url에 대한 요청에는 항상 같은 결과가 응답되어야 한다.
또한, 리소스의 조작은 HTTP메소드에 따라 지정되며, 결과는 XML, HTML, JSON 등으로 받게된다. 처리결과는 HTTP 상태코드로 알리는 것을 원칙으로 하고 있다.
HTTP Method
- GET: 조회
- POST: 생성
- DELETE: 삭제
- PUT: 대체(리소스 전체를 교체)
- PATCH: 수정(리소스 일부 수정)
REST API와 그렇지 않은 예
유저정보를 작성, 취득, 갱식, 삭제를 하는 시스템이 있다고 가정한다. REST한 설계개념을 시스템에 적용하지 않는 사람이라면 각각의 처리를 위해 아래와 같이 각각의 url을 만드는 방법을 생각할 것이다.
- 신규작성: '/create'
- 갱신: '/update'
- 삭제: '/delete'
- 취득: '/get'
하지만 RESTful API에서는 다음과 같이 된다.
- 신규작성: POST '/user'
- 갱신: PUT '/user'
- 삭제: DELETE '/user'
- 취득: GET '/user'
즉, 목적에 따라 HTTP의 일반적인 Request Method을 사용하는 것이다.
RESTful API의 장점과 단점
- 장점
- 애플리케이션의 리소스가 uri에 표시된다.
- url에 규칙이 생기므로 개발자가 이용하기 편리하다.
- Stateless하므로 확장성이 향상된다.
- 표준적인 API을 제공한다.
- 단점
- 프로그래밍 언어는 리소스 지향이 아니기 때문에 uri와 맵핑하는 코드가 더러워지기 쉽다.
프로젝트 Server API에 적용
현재 진행중인 프로젝트는 많은 기능이 요구되지 않아 충분히 REST한 API의 사용이 어려웠지만, REST API에서 요구하는 사항을 만족시키기 위해 노력하였다.
- 산책로의 정보를 취득/작성하는데 있는 있어 같은 End Point이지만 Method를 분리하여 이용
- uri는 소문자로 표기
- uri에 사용되는 단어는 단/복수형 구분
REST API 적용 전
| Method | End Point | Usage |
|---|---|---|
| POST | /main/signup | 회원가입 |
| POST | /main/signin | 로그인 |
| GET | /trails | 모든 산책로 정보 취득 |
| GET | /trails/detail | 특정 카테고리(태그)의 정보 취득 |
| POST | /trails/addtrail | 신규 산책로 정보 작성 |
REST API 적용 전
| Method | End Point | Usage |
|---|---|---|
| POST | /signup | 회원가입 |
| POST | /signin | 로그인 |
| GET | /trails | 모든 산책로 정보 취득 |
| POST | /trails | 신규 산책로 정보 작성 |
| GET | /trails/:tag | 특정 카테고리(태그)의 정보 취득 |
| GET | /trails/:tag/:trailId | 특정 카테고리 중 하나의 게시글 정보 취득 |
