Rest API와 Restful API는 프론트엔드 개발자, 백엔드 개발자 등 웹개발자라면 누구나 알고 있어야하는 부분인 것 같다. 이번에 리액트 + 스프링부트 프로젝트를 진행하며 API를 직접 만들다보니 이 부분에 대해서 확실하게 짚고 넘어가야할 것 같다. REST, API, REST API, RESTful API에 대해서 알아보고 이를 바탕으로 기존에 만들었던 스프링부트 코드를 리팩토링해보고자한다.
1. API란?
먼저 API란 Application programming Interface의 약자로 애플리케이션을 프로그래밍하는데 쓰이는 인터페이스라고 할 수 있다. 여기서 인터페이스라는 것은 컴퓨터를 하기 위해 만지고 보고 하는 화면, 키보드, 마우스 등의 모든 것을 의미하는데 사용자와 기기를 연결해주는 중간다리 역할을 하는 것이라고 생각하면 될 것 같다. 다시 말해, 즉, API라는 것은 프로그램과 프로그램 사이를 연결하는 중간다리 역할을 하며, 클라이언트와 서버의 중간 역할을 수행한다고 할 수 있다.
알기 쉽게 말하자면 손님과 점원, 요리사가 있을 때, 손님과 요리사를 연결해주는 점원의 역할을 한다고 볼 수 있는 것이다.
2. REST란?
그렇다면 REST라는 것은 무엇일까. REST는 Representational State Transfer의 약자로 네트워크를 통해 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일이다. 기본적으로 자원, HTTP 메서드, 표현을 기반으로 한다는 특징을 가지고 있으며 아래와 같은 원칙을 따른다.
1) 자원(URI)
모든 자원은 고유한 식별자를 가지며 이를 통해 접근되는데 즉, 웹 서비스의 데이터나 기능은 각각의 URI로 표현된다.
2) HTTP 메서드
- GET : 자원을 가져오기 위해 사용
- POST : 자원을 생성하기 위해 사용
- PUT : 자원을 업데이트하기 위해 사용(전체)
- PATCH : 자원을 업데이트하기 위해 사용(일부)
- DELETE : 자원을 삭제하기 위해 사용
3) 표현(Representation)
클라이언트와 서버 간에 주고받는 데이터 표현 방식으로 주로 JSON 형식 또는 XML 형식으로 데이터를 교환한다.
3. REST API와 RESTful API
앞서 API와 REST에 대해서 알아봤는데 그렇다면 REST API는 어떤걸 의미할까? 말 그대로 REST를 기반으로 서비스API를 구현한 것이라고 생각하면 될 것 같다. 더하여 RESTful API는 REST의 원칙을 따르면서도 몇 가지 추가적인 설계 원칙과 모범 사례를 적용한 API를 의미한다.
1) REST API(RESTful API)의 기본 설계 규칙
REST API를 설계할 때는 기본적인 규칙을 참고하여 설계하는데 그 규칙은 아래와 같다.
a. 소문자를 사용한다.
- 대분자는 종종 문제를 일으키는 경우가 있어 URI를 작성할 때는 소문자를 선호한다.
b. 언더바(_) 대신 하이픈(-)을 사용한다.
- 프로그램의 폰트에 따라 언더바 문자는 부분적으로 가려지거나 숨겨질 수 있다.
- 가독성을 위해 긴 Path를 표현하는 단어는 하이픈(-)으로 구분하는 것이 좋다.
c. 행위를 포함하지 않는다.
- 행위는 URI 대산 Method를 사용하여 전달한다.
d. URI의 마지막에는 슬래시를 포함하지 않는다.
- 후행 슬래시는 의미가 전혀 없으며 혼란을 야기할 수 있다.
- URI 내의 모든 문자는 리소스의 고유 ID에 포함되며, URI가 다르면 리소스도 다르기 때문에 명확한 URI를 생성해야한다.
e. 계층관계를 나타낼 때는 슬래시 구분자를 사용해야한다.
- 슬래시(/)는 URI의 경로 부분에서 자원 간의 계층적 관계를 나타내기 위해 사용한다.
f. 파일 확장자는 URI에 포함시키지 않는다.
- 파일 확장자를 URI에 포함하지 않아야하며, 대신 Accept header를 사용한다.
g. 전달하고자 하는 자원의 명사를 사용하되, 컨트롤 자원을 의미하는 경우 예외적으로 동사를 허용한다.
- 함수와 같이 컨트롤 리소스를 나타내는 URI는 동작을 포함하는 이름으로 짓는다.
h. URI에 작성되는 영어를 복수형으로 작성한다.
2) REST API의 설계 예시
행위 | HTTP 메서드 | URI |
전체 게시글 조회 | GET | /posts |
특정 게시글 조회 | GET | /posts/:id |
게시글 작성 | POST | /posts |
게시글 전체 수정 | PUT | /posts/:id |
게시글 일부 수정 | PATCH | /posts/:id |
특정 게시물 삭제 | DELETE | /posts/:id |
기존에 내가 만들어 놓은 API URL 같은 경우는 영어를 복수형으로 작성하지 않았고, 행위를 URI에 포함시킨 상태이다. 이를 바탕으로 리액트+스프링부트 프로젝트의 API를 해당 원칙에 맞게 수정해야겠다.