REST API

REST API를 알기 전에 API가 무엇인가부터 알아야한다.

API

Application Programming Interface
애플리케이션을 프로그래밍하는 인터페이스

 

https://mystacks.tistory.com/40

API란

 

REST

REpresentational State Transfer의 줄임말

Roy T. Fielding이라는 분의 논문에서 시작되었다.
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

 

REST를 왜 만들었는가
3장에서 웹 아키텍쳐를 소개하지만 웹이 가진 힘을 많이 쓰지 못하기 때문에 웹 아키텍쳐로써 REST를 만들었다고 한다.

 

REST의 시작
0. NULL 스타일로 시작하기
아무것도 없는 거에서 시작하여 제약을 추가하기 시작하며 원하는 시스템을 만드는 것이다.

1. Client - Server
   첫 번째 제약 조건은 클라이언트-서버 구조를 이루는 것이다.
2. stateless
   두 번째 제약 조건은 무상태이다. 기본적으로 클라이언트와 서버간의 통신은 request, response 이후에 아무것도 이뤄지지 않는다.

-> 즉, 연결이 유지되지는 않는다. (= connectionless)

그렇기 때문에 client는 요청시 필요한 모든 정보를 반드시 포함하여야 하고 서버에 저장된 context를 이용할 수 없다.
따라서 세션 상태는 전적으로 클라이언트에 의해 결정된다.

 

이런 제약 조건을 통해 얻을 수 있는 것은 visibility, reliability, and scalability.

1) visibilty(가시성)
모니터링 시스템이 요청에 대한 특성을 파악하고자 할 때 request하나만 보면 알 수 있다.

2) reliability(신뢰성)
부분적 장애로부터 복구 작업이 용이하기에 신뢰성이 향상

3) scalability(확장성)
요청 사이에 상태를 저장할 필요가 없기(stateless) 때문에 서버 구성 요소가 resource를 빠르게 해제할 수 있으므로 확장성이 향상
+서버가 요청 간의 리소스 사용을 관리할 필요가 없기에 구현의 단순화

 

하지만 단점도 있다.

1) decreasing network performance
요청으로 전송되는 반복적인 데이터를 증가시켜 네트워크 성능 저하 야기 -> context를 사용할 수 없기 때문이다.

2) reducing the server's control
애플리케이션의 상태를 client에게 배치하면 client의 버전에 따라 구현이 종속되기에 일관된 애플리케이션 동작을 서버가 보장할 수 없다.

 

3. cache
네트워크 효율성 개선을 위해 캐시 제약 조건을 추가한다. 기존의 클라이언트 + 서버(stateless) 구조에서 클라이언트에 cache를 더한 것이다.캐시를 사용하기 위해선 response에 명시적 or 암시적으로 cache 사용 가능 여부가 지정되어야 한다.

캐시를 추가함으로써의 이점 = 상호 작용 평균 대기 시간 감소 (효율성, 확장성, 신속성)
하지만 단점이 있음.. -> 캐시 내의 오래된 데이터 요청이 서버로 직접 전송되었을 때 얻을 수 있었던 데이터와 크게 다르면 캐시가 오히려 안정성 감소시킬 수 있다.

 

4. Uniform Interface
REST는 통일된, 균일한 인터페이스를 강조한다. 기존의 아키텍쳐와는 다른 부분이다.

1) 전체 시스템 이키텍쳐가 단순화되고 상호 작용의 가시성이 향상된다.
2) 구현과 서비스가 분리되기에 각각의 단에서 독립적인 발전을 이뤄질 수 있다.

 

그러나 단순화됨으로 인해 정보가 항상 표준화된 형식으로 전송되기 때문에 uniform interface가 오히려 효율성을 저하시킬 수도 있다는 것이다. -> 그래서 대규모 Hypermedia 데이터 전송에 효율적으로 설계되어 일반적 웹 사이트에 경우 최적화되어 있는 설계이다.
그러나 B.U.T. 다른 형태의 아키텍쳐 상호 작용 간에는 효율이 떨어진다.

 

5. Layered System
계층화된 시스템 스타일을 사용하면 각 구성 요소가 상호 작용하는 다른 계층을 볼 수 없도록 하여 복잡성, 독립성, 보안성을 갖출 수 있다.
또한 계층을 통해 legacy서비스를 캡슐화할 수 있고 legacy client로 부터 서비스를 보호할 수 있다.
계층 시스템의 단점은 데이터 처리시 반복적 데이터 요청과 지연이 증가하여 퍼포먼스 하락이 올 수 있으나 캐시를 통해 상쇄 가능하다.

 

6. Code-On-Demand

REST를 사용하면 Applet이나 Script 형태의 코드를 다운로드하고 실행하여 Client 기능 확장이 가능해진다.
이를 통해 Client가 사전 구현해야하는 기능의 수를 줄여 Client를 단순화 + 배포 후 기능 다운로드 시 확장성 또한 향상

---

REST API 원칙 가이드

1. 자원의 식별
   WEB 기반 REST 시스템에서의 URI처럼 요청 내 기술된 개별 자원을 식별할 수 있어야 한다.
   자원 그 자체는 Client가 받는 문서와는 개념적으로 분리되어 있음 -> server는 DB의 data 자체를 보내기보다 HTML, XML, JSON 등의 형식으로 serializer해서 보내는 것
2. 리소스의 조작
   client가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면, 이것으로 Server 상 해당 자원 변경 및 삭제가 가능
3. 자기서술적 메시지
   각 메시지는 자신을 어떻게 처리해야 하는지에 대해 충분한 정보를 포함해야 한다.

REST API

REST의 제약조건과 원칙을 지키는 API라는 것
서버-클라이언트 구조를 가지고 있고 stateless한 특성을 가지고 캐시가 사용가능해야하며 균일한 interface를 통해 정보를 제공하고 계층구조를 갖고 있으며 서버는 실행 가능한 코드를 전송해야한다.

여기에 더하여 HTTP에 관한 요소가 필요하다.

1. 자원 - URI
   URI는 행위가 아닌 자원의 위치를 나타내기 때문에 명사를 사용해야한다.
2. 행위 - HTTP Method
   method를 통해 행위를 나타내야한다. 삭제라는 행위를 하기 위해서는 DELETE method를 사용해야하는 것
3. 표현 - 메시지
   HTTP 응답 코드를 나타내며 2xx~5xx까지 존재한다
   200번대 = 성공
   300번대 = redirection
   400번대 = client error
   500번대 = server error