post-custom-banner

RESTful API

RESTful API란?

Representational State Transfer API의 약어로, HTTP 프로토콜을 기반으로 하여 클라이언트와 서버 간 통신을 할 수 있도록 설계된 API이다. RESTful API는 리소스 지향 아키텍처를 따르며, URI(Uniform Resource Identifier)를 이용해 서버의 리소스에 접근한다.

그전에 'REST'...는 무엇인가?

REST 개념 설명 이미지 Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다. REST는 처음에 인터넷과 같은 복잡한 **네트워크에서 통신을 관리하기 위한 지침**으로 만들어졌다. REST 기반 아키텍처를 사용해 대규모의 고성능 통신을 안정적으로 지원할 수 있게 되었다. 이렇게 REST 아키텍처 스타일을 따르는 API를 REST API라고 하며, REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다. RESTful API라는 용어는 일반적으로 RESTful 웹 API를 의미한다.

(+) REST 아키텍처 스타일의 몇 가지 원칙을 알아보자.

Style 1. 균일한 인터페이스
모든 RESTful 웹 서비스 디자인의 기본으로, 서버가 표준형식으로 정보를 전송함을 나타낸다. 형식이 지정된 리소스를 REST에서 표현이라고 부른다. 이 형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있다.
  균일한 인터페이스를 위한 4가지 아키텍처 제약 조건
  1) 요청은 리소스를 식별해야 하므로 균일한 리소스 식별자를 사용한다.
  2) 클라이언트는 원하는 경우, 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 갖고 있다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송해 이 조건을 충족한다.
  3) 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송한다.
  4) 클라이언트는 작업을 완료하는 데 필요한다른 모든 관련 리소스에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송한다.

Style 2. 무상태
여기서 '무상태'는 서버가 이전의 모든 요청과는 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 의미한다. 클라이언트는 임의의 순서로 리소스를 요청할 수 있으며, 모든 요청은 무상태이거나 다른 요청과 분리된다. 이 REST API 설계 제약 조건은 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미한다.

Style 3. 계층화 시스템
계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 중개자에게 연결할 수 있으며, 여전히 서버로부터도 응답을 받는다. 서버는 요청을 다른 서버로 전달할 수도 있다. 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수도 있다. 이런 계층은 클라이언트에게 보이지 않는 상태로 유지된다.

Style 4. 캐시 가능성
RESTful API 웹서비스는 서버 응답 시간을 개선하고자 클라이언트 또는 중개자에게 일부 응답을 저장하는 프로세스인 '캐싱'을 지원한다. 예를 들어 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문한다고 가정해보자. 새로운 웹 사이트 페이지를 방문할 떄마다 서버는 동일한 이미지를 재전송해야 한다. 이를 피하기 위해 클라이언트는 첫 번째 응답 후, 해당 이미지를 캐싱하거나 저장한 후, 캐시에서 직접 이미지를 사용한다. RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용해 캐싱을 제어한다.

Style 5. 온디맨드 코드
REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송해 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다. 예를 들어, 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시하여 알린다. 서버에서 전송한 코드 덕분에 우리는 이 작업을 수행할 수 있다.


RESTful API 사용 이점은?

▶️ 확장성

REST API 구현 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기를 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요 없기 때문에 서버 로드를 제거하한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적/완전히 제거한다. 이러한 모든 기능은 성능 저하의 원인 중 하나인 병목 현상을 일으키지 않으면서도 확장성을지원한다는 장점이 있다.

▶️ 유연성

RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원하는데, 이때 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시키게 된다. 이에 대한 예시로, 개발자는 애플리케이션 로직을 재작성하지 않고도 데이터베이스 계층을 변경할 수 있다.

▶️ 독립성

REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고, 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한, 통신에 영향을 주지 않은채 양쪽의 기본 기술을 변경할 수 있다는 장점이 있다.


RESTful API 작동원리

RESTful API의 기본 기능은 인터넷 브라우징과 동일하다고 한다. 클라이언트는 리소스가 필요할 때 API를 사용해 서버에 접속하고, API개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지를 설명한다. 아래는 모든 REST API 호출에 대한 일반적인 단계이다.

1️⃣ 클라이언트가 서버에 요청을 전송한다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다.
2️⃣ 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지를 확인한다.
3️⃣ 서버가 요청을 수신하고, 이를 내부적으로 처리한다.
4️⃣ 서버가 클라이언트에 응답을 반환한다. 응답에는 요청이 성공했는지의 여부를 클라이언트에 알려주는 정보가 포함된다. 응답에는 클라이언트가 요청한 모든 정보도 포함된다.

REST API 요청 및 응답 세부 정보는 API 개발자가 API를 설계하는 방식에 따라 약간씩 다를 수 있다.


참고한 글
📚 AWS__ RESTful API란 무엇인가요?
📚 REST, REST API, 그리고 RESTful API란? (💡🌟)

profile
예비 프론트엔드 개발자, 아기 binu
post-custom-banner

1개의 댓글

comment-user-thumbnail
2023년 4월 2일

안녕하세요, 제로베이스 프론트엔드스쿨 멘토입니다. 작성해주신 글 잘 읽었고, 앞으로의 더 나은 블로깅을 응원하는 마음에서 작은 의견을 남기고 갑니다 :)

  • 전체적으로 내용상의 오류 없이 잘 작성해주셨습니다.
  • 참고 자료를 잘 정리해주셔서 좋았습니다.
  • REST의 원칙들을 설명해주시는 부분에서, '균일한 인터페이스', '무상태' 등과 같이 한글로 풀어서 설명해주셨는데요, 개발 관련된 키워드는 검색 용이성과 이해도를 높이기 위해 영문으로 한번은 병기해주시면 좋을 것 같습니다. 예) uniform interface, stateless
  • 다만, 글 전체적으로 외부에서 가져온 내용을 재구성해주신 느낌이 살짝 들어서, 제가 면접관 등 제 3자의 평가자라면 이 글을 다 읽고, '그래서, RESTful API가 뭔지 정확하게 이해했는가?'에 대한 Question이 생길 수도 있을 것 같습니다. 첫 줄에 적어주신 내용이 사실 핵심에 가깝지만, 작성해주신 내용만을 봤을 때는 정말 정확하게 이해했는지가 살짝 모호한 것 같기는 합니다. REST는 아키텍처 스타일입니다. HTTP와 같은 규칙은 아닙니다. 즉, REST를 지키지 않는다고 해서 에러가 발생하거나 통신이 안되거나 하지는 않습니다. 지키면 좋은거고, '우리 이렇게 다같이 지켜서 통신해보지 않을래?'라는 일종의 스타일의 제안인 것입니다. 그래서 사실 우리가 개발하는 API는 RESTful하지 않은 경우도 많구요..! 간략하게 설명을 드렸지만, 학습해본 내용을 한번 더 정리해보시고, 글 전체적으로 이 REST에 대해 정확하게 이해했다는 것이 잘 드러나도록 사이사이를 다듬어주면 좋을 것 같습니다.

감사합니다 :)

답글 달기