RESTful API

RESTful

RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 언어이다.

그럼 REST가 무엇일까?

REST

REST(Representational State Transfer)는 WWW(World Wide Web)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.

REST 아키텍처

REST 아키텍처를 사용하는 이유 및 특징

1. 일관성(인터페이스의 일관성)
2. 계층화

URL 설계규칙

1. /(슬래쉬)는 계층 관계를 나타내는데 사용
2. 마지막 문자로 /를 포함하지 않는다.
3. CRUD 동사를 쓰지 않는다.
4. 기능에 적절한 HTTP Method를 사용한다.
5. 언더바 대신 '-' 하이픈을 사용
6. 소문자 사용
7. URI에 파일 확장자를 포함하지 않는다. 예).exe, .html 등등
8. 명사에는 되도록 단수형 보다, 복수형을 사용한다.

---

REST와 RESTful의 차이

• REST : 웹상의 자원을 이름으로 구분하고 해당 자원의 상태를 주고 받는 모든 것을 의미하고 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하는 아키텍처 스타일이다.

• RESTful : REST를 기반으로 만들어진 API이며, REST 원칙을 잘 지킨 서비스 API를 의미합니다.

그러면 API와 REST 원칙이 무엇일까?

API

API(Application Programming Interface)는 응용프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

REST의 기본 원칙

1. Client-Server
사용자 인터페이스에 대한 관심사와 데이터 스토리지 문제에 대한 관심사를 분리하여, 인터페이스가 변경되지 않는 한 클라이언트와 서버가 서로 의존하지 않고 독립적으로 발전할 수 있어야한다.

-> 확장을 쉽게 할 수 있다는 뜻은 '분산 시스템'을 효율적으로 사용할 수 있다는 뜻이다.

2. Stateless

클라이언트에서 서버로의 각 요청에는 요청을 이해하는 데 필요한 모든 정보가 포함되어야하며, 서버에 저장된 컨텍스트를 이용할 수 없다. 따라서 세션 상태는 전적으로 클라이언트에 유지되어야한다.

-> Stateless의 규칙을 지킴으로, 확장을 쉽게할 수 있다.

3. Cacheable

네트워크 효율성을 개선하기 위해 캐시 제약 조건을 추가했다. 요청에 대한 응답 내에 캐싱이 가능한 지 여부에 대한 라벨링을 해야 한다. 만약 응답에 cacheable 하다고 되어 있으면 클라이언트는 동일한 요청에 대해서 응답 데이터를 재사용할 수 있게 된다.

-> ex) HTTP Header의 cache-control

4. Uniform Interface

API를 사용하는 클라이언트들에게 노출될, API 자원에 대한 균일한 API 인터페이스를 결정해야만 한다. REST에서 말하는 균일한 인터페이스를 얻으려면, 구성 요소의 동작을 안내하는 4가지의 제약을 따르라고 한다.

1) 리소스 식별

-> 리소스가 URL로 식별되면 된다.

비디오, 문서, 이미지 등과 같은 이름을 지정할 수 있는 것은 모두 리소스이다. URI(Uniform Resource Identifier)라는 고유 식별자를 사용하여 리소스를 식별한다.

HTTP를 통해 REST API를 빌드하면, URL을 사용하여 API에서 액세스하는 리소스를 식별 할 수 있다. REST 제약 조건을 충족하려면 각 URL이 단일 리소스에 매핑되어야 하며 이 리소스에 대한 모든 액세스는 해당 URL을 통해 수행된다.

즉 특정 리소스는 오직 하나의 URL만 가져야 한다.

2) 표현을 통한 자원 조작

-> 특정 리소스를 나타내는 URL을 바꾸지 않고도, 표현을 활용해서 리소스를 조작할 수 있다.

• RESTful 애플리케이션은 동일한 URI에서 동일한 리소스의 두 개 이상의 표현을 지원할 수 있다.

• HTTP 메서드인 GET, POST, PUT, DELETE 등을 황용해서 리소스를 조작할 수 있다.

3) 자기 서술적인 메시지

-> 요청, 응답과 같은 메시지는, 메시지 그 자체만 보고 무슨 의미인지 파악할 수 있을 정도로 정보가 담겨있어야 한다.

RESTful 시스템에사 제공하는 표현에는 클라이언트 리소스를 이해하고 조치를 취하는 데 필요한 모든 데이터가 포함되어야 한다. 추가 정보가 필요하지만 응답에 포함되지 않은 경우에는, 해당 추가 정보를 가지고 있는 링크가 응답에 제공되어야 한다. 즉 응답하기 위해 선택한 미디어 유형은 자체 문서화 되어야 하며, 클라이언트가 관심을 가질 수 있는 모든 관련 리소스 또는 작업을 응답에 정보로 포함시켜야 한다.

4) HATEOAS(hypermedia as the engine of application state)

-> 애플리케이션의 상태가 Hyperlink를 이용해 전이되어야 한다.

• 어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이 될 수 있는 상태가 결정된다. 쉽게 말해서 링크는 동적으로 변경될 수 있다.

• 리소스를 고유하게 식별하고, 표현을 사용하여 리소스 상태를 전달하고, 미디어 타입을 통해 self-descriptive 메시지를 사용함으로써 모든 애플리케이션 상태가 클라이언트에 유지된다. 모든 애플리케이션 상태를 클라이언트에 유지함으로써, 클라이언트와 서버 간의 직접 연결이 필요하지 않게 된다. 이로써 최소한의 리소스로 많은 클라이어늩에 서비스를 제공하도록 서버를 확장 할 수 있다. 이런 특징은 웹을 확장 가능하고 탄력적으로 만들어주었다. 결론적으로 REST 제약 조건으로 API를 설계함으로써, 확장 가능하고 탄력적인 API를 구축 할 수 있다.

• 특정 리소스가 다른 리소스와 관련 있을 때에는, 특정 리소스가 다른 리소스의 관련 정보를 가져올 수 있게 URI를 의미하는 링크(HATEOAS)를 포함해야 한다.

5. Layered System

계층형 시스템 스타일을 사용하면, 각 구성 요소가 상호 작용하는 직계 계층 너머를 볼 수 없도록 구성 요소 동작을 제한하여(=캡슐화하여) 아키텍처를 계층적으로 구성해야 한다.

6. Code on Demend(Optional)

• 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다.
  -> ex) 서버로부터 받은 JavaScript 파일을 브라우저에서 실행 시킬 수 있다.
  

• REST를 사용하면 애플릿 또는 스크립트 형태로 코드를 다운로드하고 실행하여 클라이언트 기능을 확장 할 수 있습니다. 이는 사전 구현에 필요한 기능의 수를 줄여 클라이언트를 단순화합니다.