[네트워크] REST, REST API, RESTful 알아보기

REST

• 자원을 이름으로 구분하여 해당 자원의 상태 및 정보를 주고 받는 모든 것을 의미
• 웹의 기존 기술과 HTTP 프로토콜을 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
• 네트워크 상에서 Client와 Server 사이의 통신 방식
• HTTP URI를 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것

 

REST 구성 요소

• 자원(Resource)
  • URI로 표시
  • 모든 자원에 대한 고유 ID(URI)가 존재하고, 이 자원은 Server에 존재
  • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청
• 행위(Verb)
  • HTTP 프로토콜의 Method 사용
• 표현(Representation of Resource)
  • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냄
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있음
  • JSON이나 XML를 통해 데이터를 주고 받는 것이 일반적

 

REST 특징

• Server-Client(서버-클라이언트 구조)
  • 자원을 가지고 있는 쪽은 Server, 자원을 요청하는 쪽은 Client
  • 서버와 클라이언트 서로 간의 의존성 낮음
• Stateless(무상태)
  • HTTP 프로토콜의 Stateless 속성을 그대로 가지고 있음
  • Client의 context 정보(쿠키, 세션 등)를 Server에 저장히지 않아 구현 단순
  • Server는 각각의 요청을 별개로 인식하고 각각 처리 -> 처리 방식의 일관성 부여, 서비스 자유도 향상
• Cacheable(캐시 처리 가능)
  • HTTP 프로토콜의 캐싱 기능 활용 가능
  • 대용량 요청의 효율적 처리 가능
  • 캐시 사용을 통해 서버의 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률 향상
• Layered System(계층화)
  • Client는 REST API Server만을 호출
  • REST Server는 다중 계층으로 구성 가능
    • 순수 비즈니스 로직을 처리하는 API 서버 앞에 보안, 로드밸런싱, 암호화, 사용자 인증 등의 서버 계층을 추가하여 구조상의 유연성 제공 가능
  • 프록시, 게이트웨이와 같은 네트워크 기반의 중간 매체 활용 가능
• Code-On-Demand(optional)
  • Server로부터 제공받은 리소스 처리에 대한 코드를 Client에서 실행
  • 반드시 충족할 필요 X
• Uniform Interface(인터페이스 일관성)
  • URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능

 

REST 장단점

• 장점
  
  • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요 X
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
  • URI 자원 명시를 통해 REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악 가능
  • 서버와 클라이언트의 역할이 명확히 분리
  • 각종 브라우저, 모바일 디바이스 등 다양한 클라이언트 및 멀티 플랫폼에 대한 서비스 지원 용이
• 단점
  • 표준 존재 X
  • 사용할 수 있는 메서드가 형태가 제한적 (only HTTP Method)
  • 구형 브라우저의 경우 지원하지 않는 부분이 존재

 

<참고> REST vs GraphQL

• REST
  • HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 자원에 대한 CRUD를 적용
  • 서버와 클라이언트의 역할이 명확히 분리되며 RestAPI의 메시지가 의도하는 바를 쉽게 파악 가능
  • 여러 엔드포인트를 가지며 엔드포인트에 따라 정해진 응답만을 받아올 수 있음
• GraphQL
  • 클라이언트가 필요한 데이터를 얻도록 하는 일종의 쿼리 언어
  • 백엔드가 정해놓는 틀이 없어 유연함
  • 하나의 엔드포인트를 가지며 요청할 때 사용하는 쿼리에 따라 다른 응답(원하는 데이터만)을 받을 수 있음

 

 

REST API

• REST를 기반으로 서비스 API를 구현한 것
• REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
• REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트와 서버를 구현할 수 있음

 

REST API 설계 원칙

- 도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
- 컬렉션 : 서버에서 관리하는 디렉터리라는 리소스
- 스토어: 클라이언트에서 관리하는 리소스 저장소

• URI에서 자원은 동사보다는 명사를, 대문자보다는 소문자 사용
• URI에서 자원의 도큐먼트 이름은 단수 명사 사용
• URI에서 자원의 컬렉션 이름은 복수 명사 사용
• URI에서 자원의 스토어 이름은 복수 명사 사용

 

• URI에 HTTP Method 이름 명시 X
  • ex) delete, post, get
• URI에 행위에 대한 동사 표현(기능 표현) 명시 X
  • ex) show, insert
• 경로 부분 중 변하는 부분은 유일한 값으로 대체 (고유 ID를 활용해 자원 특정)
  • ex) students/12

 

• 슬래시 구분자(/)는 계층 관계를 나타내는데에 사용
• URI 마지막 문자를 슬래시(/) 포함 X
• 하이픈(-)은 URI의 가독성을 높이기 위해 사용 가능
• 언더바(_)는 사용 X
• URI에 파일 확장자(.jpg 등) 포함 X
• 리소스 간 연관 관계가 있는 경우: /리소스명/리소스 ID/연관 있는 다른 리소스 명
  • ex) /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

 

 

RESTful

• "RESTful 하다": REST API를 제공하는 웹 서비스
• "RESTful 하지 않다": CRUD 기능을 모두 POST로 처리하거나 REST API 설계 원칙을 따르지 않은 경우
• REST를 REST답게 쓰기 위한 방법 (REST 원리를 따르는 시스템)