RESTful API란 무엇인가?

### 시작하기에 앞서

해당 글은 면접을 보기 전 RESTful API에 대한 생각을 정리하기 위한 글이다.

개념 파악이나 활용에는 적합하지 않을 수 있으나 다양한 생각을 접하는 것을 좋아하는 사람이라면 도움이 될 수도 있을 것이다.

혹여 잘못된 정보가 있다면 단호하게 틀렸다고 말해주면 고맙겠다.(당신이 바로 해당 블로그의 첫번째 댓글러가 될 수 있음)

### REST란?

REST는 Representational State Transfer의 약자이다. 번역기 돌리면 '대표 상태 전이'이란 뜻인데 뭔소린지 모르겠다면 정상이다. 

조금 더 풀어서 설명하자면 '자원'이라는 키워드를 추가하여 '자원의 상태를 전달한다'는 뜻으로 이해하면 된다.

HTTP 웹의 창시자 중 한명인 로이 필딩(Roy Fielding)의 논문(2000년)에 소개된 개념인데 웹이 가진 본연의 설계를 잘 활용할 수 있는 네트워크 아키텍쳐가 REST이다. 그리고 로이 필딩이 주장한 REST스러운 API를 RESTful API라고 한다.(거창하거나 다른 개념이 아님)

현재 웹서비스의 흐름은 SOAP기반에서 RESTful로 넘어온 상태이다.

### REST의 특징

1. Unifrom (유니폼 인터페이스)

URI 형태의 인터페이스로 HTTP 표준 프로토콜을 따르는 다양한 플랫폼에서 사용이 가능하다.

2. Stateless (무상태성)

클라이언트와 서버간에 다른 자원(세션, 쿠키)을 저장하거나 관리하지 않고 요청만 처리.

3. Cacheable (캐시 가능)

캐싱 기능을 사용가능하다는데 사실 사용해본 적은 없다.

4. Self-descriptiveness (자체 표현 구조)

REST API 메세지만 보고 이게 어떤 동작을 하는지 쉽게 이해할 수 있음.

ex) GET/members/1 -> '아~ 이건 멤버 1을 호출하는 웹서비스구나!'

5. Client - Server 구조

클라이언트는 사용자 인증 컨텍스트를 직접 관리하고 서버는 API만 실행한다는 의미로 역할이 구분되어 있으며 의존성이 줄어든다.

6. 계층형 구조

REST Server는 다중 계층으로 구성하여 보안, 로드밸런싱, 암호화, 사용자 인증 / 비즈니스 로직단 같이 구분된 형태로 구현이 가능하다.

###  RESTful API 공식 가이드? 

여기서 생각해볼 점은 과연 모두가 RESTful하게 API를 만들고 있냐란 점이다. 슬프게도 RESTful하게 사용하는 곳은 많지 않다.(개인적인 경험에 입각하므로 아닐 수도 있다. 오히려 아니길 바란ㄷ..) 왜냐하면 공식 가이드 라인이 없기 때문이다. 공식에 가장 가까운 것은 로이 필딩의 논문(https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)을 보고 적용해야 하는데 어떤 기관이 존재하지 않는 이상 개인의 해석이 들어갈 수 밖에 없기 때문이다. 그래서 실무에서는 미세한 차이들이 존재하는 다양한 형태의 RESTful 설계를 볼 수 있다.(REST의 특징을 하나도 지키지 않지만 RESTful API라고 하기도 한다 - 잘못된 예) 결국 표준이 없고 스타일에 가깝기 때문에 'ful'이란 뉘앙스가 붙는 것이기도 하다. (실제로 구글, 페이스북, 아마존, 트위터 등등 형태가 다 다르고 기능 마다 형태가 다른 경우도 있다)

### RESTful API 설계

앞에서 말한 것처럼 표준은 없지만 어느 정도 인기있는 스타일?은 존재한다.

ex) 좋은 예 - GET/users/12345 

     나쁜 예 - GET/api?type=user&id=23

그러나 결국에 정답은 없으므로 최소한의 규칙을 준수하면서 자신의 팀과 의논하여 해당 서비스에 가장 알맞은 형태로 구현하는게 가장 좋을 것이다. 확장성과 유지보수, 안정성까지 생각해야 할테니 말이다.

### 좋은 RESTful API란 무엇일까?

핵심은 기본 개념을 지키는 것이다.

1. resources는 심플하지만 명확하여 의미 전달이 잘 된다.

2. HTTP기본 메서드(GET, PUT, POST, DELETE)를 활용한 확장성과 그 의미를 잘 준수하여 설계한다.

   ex) GET = read, POST = create, ...

3. HTTP response status codes를 온전히 작성한다.

4. Versioning을 사용한다.

   ex) https://api.example.com/v1/authors/2/blogspots/13

RESTful API 자체가 그리 어려운 개념은 아니라고 생각한다. 하지만 실제 만들어진 API를 통해 서비스를 하려고 한다면 분명 많은 것들을 생각해야 할 것이고 여기서 가장 필요한 것이 '커뮤니케이션 능력'이 아닐까 생각한다. 어떻게 하면 더 의미가 잘 전달될 수 있을지. 속도와 안정성을 개량할 수 있을지 등등. 백엔드 뿐만 아니라 프론트엔드와 커뮤니케이션 또한 굉장히 중요할 것이다.

결론은 좋은 서비스는 안정적인 웹서비스의 공급에서 시작되고 안정적인 웹서비스는 원활한 커뮤니케이션에서 나온다는 것이다. 물론 매우 개인적인 생각이다  : )

### 참고 자료

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

https://code-maze.com/top-rest-api-best-practices/#restbound

https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

https://www.restapitutorial.com/