[TIL] RESTful API

REST

REST(Representational State Transfer)란,
월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로,
자원을 정의하고 자원에 대한 주소를 지정하는 방법의 모음을 일컫는다.

... 정의가 한 번에 알아듣기에는 워낙 어렵다보니 천천히 짚어보고 다시 이해해보자 :)

REST의 구성 요소

REST는 크게 ①리소스 ②메서드 ③메세지 이렇게 3가지 요소로 구성된다.

예를 들어, "이름이 John인 사용자를 만든다."라는 호출을 분석해보면

• 생성되는 사용자 [리소스]
  : https://localhost:8080/users 와 같은 URI(Uniform Resource Identifier)
    즉, 리소스를 나타내는 주소의 형태
• 생성하는 행위 [메서드]
  : POST http://localhost:8080/users 와 같은 HTTP 메서드 형태
• 이름이 John인 사용자 [메세지]

   {
    "username": "John"
   }

      내용을 담고 있는 JSON 문서의 형태로 구성된다.

즉, 종합해본다면 REST는 아래와 같은 형식으로 표현될 수 있다.

POST http://localhost:8080/users

{
  "username": "John"
}

---

REST에는 예시의 POST뿐만 아니라, CRUD(Create, Read, Update, Delete)에 해당하는
다음과 같은 4가지 HTTP 메서드(+1)가 있다는 것도 알아두도록 하자.

• POST(Create)
  : 리소스를 생성한다.
• GET(Read)
  : 리소스를 조회한다.
• PUT(Update)
  : 리소스를 수정한다.
• DELETE(Delete)
  : 리소스를 삭제한다.

   • PATCH
      : PUT과 마찬가지로 리소스를 수정하는데 사용되지만,
        PUT에 비해 주의사항이 많으며 지원하지 않는 브라우저가 많다.

---

위키피디아에 명시된 정의만 보면 다소 복잡해보이지만,
앞서 다룬 개념을 바탕으로 REST란 ①HTTP URI를 통해 리소스를 명시하고, ②HTTP 메서드를 통해
③해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다는 것을 알 수 있다.

다른 블로그에서는 이를 간단히 풀어 URI와 HTTP 메서드를 통해 객체화된 서비스에 접근하는 것이라고 정의 내리는 것도 보았다.

개인적으로는 REST의 구성요소를 하나하나 분리해서 살펴보고 이해하니 그 의미가 좀 더 쉽게 와닿는 것 같다.

REST의 6가지 기본 원칙

• 인터페이스 일관성 : 일관적인 인터페이스로 분리되어야 한다
• 무상태(Stateless): 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
• 캐시 처리 가능(Cacheable): WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
  잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다.
• 계층화(Layered System): 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
• Code on demand (optional) - 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
• 클라이언트/서버 구조 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.

(출처: 위키피디아)

API

API(Application Programming Interface)란,
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며,
서로 정보를 교환가능 하도록 하는 것이다.

AWS에 설명되어 있는 바로는 다음과 같다.

API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다. 예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 ‘대화’하여 휴대폰에 매일 최신 날씨 정보를 표시합니다.

ㅡ AWS(Amazon Web Service)

즉, 컴퓨터 프로그램/소프트웨어 간의 상호작용 및 의사소통을 가능하게 해주는 매개체 정도로 이해하면 될 것 같다.

RESTful API

앞서 REST와 API에 대해 다뤄보았다.
그렇다면 'RESTful API'는 무엇이란 말인가? 단어 그대로 REST한 API를 의미한다.
즉, REST의 특징이나 원칙, 규칙에 알맞게 디자인 된 API라는 것이다.

REST API의 URI 설계 규칙

• URI는 전달하고자 하는 리소스의 명사를 사용하되,
  컨트롤 자원을 의미할 때는 예외적으로 동사를 허용한다.
• /로 계층 관계를 표현한다.
• URI의 마지막에는 /를 포함하지 않는다.
• URI는 소문자를 사용한다.
• _ 대신 -을 사용한다.
• HTTP 응답 상태 코드를 사용한다.
• 파일확장자는 URI에 포함하지 않으며,
  불필요하면 파라미터를 넣지 않는다.

(출처: pjh612's velog)

위의 규칙들이 잘 지켜진 API가 RESTful API가 되는 것이다.

이렇게 디자인 된 RESTful API는 다음과 같은 장/단점을 지닌다.

RESTful API의 장점

• HTTP 프로토콜의 인프라를 그대로 사용하기 때문에,
  REST API를 위한 별도의 인프라를 구축하지 않아도 된다.
• API 명세서를 읽지 않아도 요청을 알아보기 쉽고 간결하다.
• 범용성이 뛰어난 편이다.

RESTful API의 단점

• 비표준화. 즉, 공식화된 레퍼런스가 없기에, 사람마다 다르게 해석하여 사용할 수 있다는 것이다.
• 모든 케이스에 완벽하게 적용된다고 보기는 어렵다.
  굉장히 복잡한 구조의 경우 REST로 디자인했을 때 오히려 구현하기 힘든 경우가 있다.
• 구형 브라우저에서는 작동하지 않는 HTTP 메서드나 상태코드들이 있다.