[Network] REST, RESTful API 개념 정리

내가 REST API형식에 맞게 개발을 하고 있음에도 REST API가 정확히 뭔지 설명하기 힘들때가 많다. 이 글을 봤을 때 머릿속에 흩어져있던 개념이 한번에 맞춰지도록 작성해보려고 한다.

우선 REST API에서 API부터 살펴보자. API는 Application Programming Interface의 약자로 어플리케이션들 사이에서 데이터 교류를 할 수 있도록 해주는 통신방법이다. 일례로 우리가 기상청에서 날씨데이터를 받아올때도 기상청의 날씨API형식에 맞게 데이터를 요청해야하며 기상청측에서도 날씨API형식에 맞게 데이터를 응답을 해야 할 것이다. 프로젝트를 하다보면 데이터를 얻기위해서 여러사이트의 API를 이용하곤하는데, 각 사이트의 API형식에 맞지 않은 채로 데이터요청을 한다면 데이터를 제대로 받지 못할 것이다.

그렇다면 REST API는 뭘까?

말그대로 REST한 API이다. applications사이에서의 통신방법인 API이긴 한데, REST하다는 것이다. REST규칙에 맞게끔 데이터를 주고받는다고 하면 쉽게 이해가 될 것이다. REST 규칙은 각 요청이 어떤 정보를 위한 것인지를 그 모양새에서 추론이 가능하다는,, 개발자 입장에서 아주 편리한 규칙을 가진다.

REST API 설계 기본 규칙

1. URI는 정보의 자원을 표현해야 한다.

• 자원은 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
• 자원의 도큐먼트 이름으로는 단수 명사를 사용해야 한다.
• 자원의 컬렉션 이름으로는 복수 명사를 사용해야 한다.
• 자원의 스토어 이름으로는 복수 명사를 사용해야 한다.

2. 자원에 대한 행위는 HTTP 메서드(GET, POST, PUT, DELETE 등)로 표현한다.

• URI에 HTTP 메서드가 들어가면 안된다.

                  Ex) GET /users/delete/1 -> DELETE /users/1

• URI에 행위에 대한 동사표현이 들어가면 안된다.(CRUD기능을 나타내는 것은 URI에 사용하지 않는다.)

                   Ex) GET /users/show/1 -> GET /users/1

                   Ex) GET /users/insert/2 -> POST /users/2

자세한 규칙에 대해서는 다음 블로그를 참고하자. https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

이런식으로 REST의 원리를 따르는 API를 RESTful API라고 한다. 다만, 모든 CRUD 기능을 POST로 처리하는 API를 만들었다면, 이는 REST API를 사용했지만, RESTful한 API는 될 수 없다. 만든 API가 어떤 기능을 하는지 HTTP 메서드로 적절하게 설명할 수 있어야 한다.

 

정리

한마디로 정리하자면, REST API란 HTTP요청을 보낼때 URI에 어떤 메소드를 사용할지에 대해서 개발자들 사이에 지켜지는 약속이다. REST API는 형식이기 때문에 기술에 구애받지 않는다. 따라서 어떤 소프트웨어를 쓰던 어떤 언어로 무엇을 만들던 간에 소프트웨어간 HTTP로 정보를 주고받는 부분이 있다면 RESTful한 API를 만들 수 있을 것이다.