REST API

CS 학습 스터디를 진행하며 발표를 진행했던 내용들을 정리하여 블로그에 공유하려고 합니다.

REST + API ?

우선 REST API에 대해 알기 전에 간략하게 API, REST에 대해서 간략하게 알아보고 갑시다.

API란?

Application Programming Interface의 약자입니다.

API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다.

컴퓨터와 인간을 연결시키는 사용자 인터페이스(UI)와 반대로, API는 컴퓨터나 소프트웨어를 서로 연결합니다.

REST란?

Representational State Transfer의 약자인 REST는 API 작동 방식에 대한 조건을 제시하는 소프트웨어 아키텍처입니다.

쉽게 말하자면 기계와 기계가 웹을 이용하여 통신을 할 때 정해진 통신 규칙입니다. 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다.

REST의 6가지 스타일 규칙

어떤 조건을 제시한 아키텍처라고 했는데요, 조건에는 어떤 것들이 있는지 살펴봅시다.

균일한 인터페이스

요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다.

형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있습니다. 예를 들어, 서버는 데이터를 텍스트로 저장하되, HTML 표현 형식으로 전송할 수 있습니다.

클라이언트-서버 디커플링

클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 한다.

클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이다.

요청된 데이터를 전달하는 것 말고는 클라이언트 애플리케이션을 수정하지 않아야 한다.

무상태 (Stateless)

REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 클라이언트 요청을 완료하는 통신 방법을 나타냅니다.

각 요청 간에 클라이언트의 정보를 저장하지 않고 분리하여 서로 연결되어있지 않아야 합니다.

이는 서버가 매번 요청을 완전히 이해해서 이행할 수 있게 해 줍니다.

계층화 시스템

호출과 응답이 서로 다른 계층을 통과합니다.

클라이언트와 서버 애플리케이션이 서로 간에 직접 연결된다고 가정 X

통신 루프에는 다수의 서로 다른 중개자가 있을 수 있다.

캐싱 가능성

가급적 리소스를 클라이언트 또는 서버 측에서 캐싱할 수 있어야 합니다.

서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다.

서버측 확정성 증가와 함께 클라이언트 측의 성능 향상을 동시에 얻을 수 있습니다.

Code on demand (optional)

일반적으로 정적인 리소스를 전송하지만 특정한 경우에는 응답에 프로그래밍 코드를 포함할 수 있다.

API 발전 타임라인

API Timeline

REST API

특정 기술을 의미하는 게 아닌 위에 설명한 두 가지 개념이 합쳐진 것입니다.

아키텍처 스타일의 디자인 원칙을 준수하는 API입니다. 이러한 이유 때문에 REST API를 종종 RESTful API라고도 합니다.

HTTP를 이용한 통신에서 HTTP가 가진 잠재력을 최대한 이용할 수 있도록 유도하는 모범사례입니다.

HTTP request method

HTTP를 사용하기 때문에 같은 메서드를 사용합니다

http method

ex - GET /movies/avatar2

REST API 설계 시 지켜야 하는 규칙

잘 설계된 REST API는 각 요청이 어떤 동작이나 정보를 위한 것인지 그 요청의 모습 자체만으로 추론이 가능하다면 베스트 케이스입니다.

1. 대문자보다는 소문자를 사용하여야 한다.


X - <http://test.com/Comment/>
O - <http://test.com/comment/>

2. 마지막에 슬래시( / )를 포함하지 않는다.


X - <http://test.com/test/>
O - <http://test.com/test>

3. 언더바 대신 하이폰을 사용한다.


X - <http://test.com/test_blog>
O - <http://test.com/test-blog>

4. 파일확장자는 URI에 포함하지 않는다.


X - <http://test.com/photo.jpg>
O - <http://test.com/photo>

5. 행위를 포함하지 않는다.


X - <http://test.com/delete-post/1>
O - <http://test.com/post/1>

장점과 단점

장점

확장성, 유연성, 독립성에서 이점을 얻을 수 있습니다.

HTTP를 사용하므로 기존 인프라를 그대로 사용할 수 있습니다.

대규모의 고성능 통신을 안정적으로 지원할 수 있습니다.

쉽게 구현, 수정이 가능해서 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있습니다.

단점

요청 메서드가 한정적입니다.

HTTP 통신 모델에 대해서만 지원합니다.

결론

API의 발전 타임라인을 통해 REST API에만 익숙했던 시야를 조금 더 넓힐 수 있었습니다. GraphQL과 같은 신기술들을 통해 단점이었던 UnderFetching과 OverFetching을 해결되는 모습 등을 통해 새로운 기술들에 대해서도 학습할 필요가 있다고 느꼈습니다.