4) hypermedia as the engine of application state (HATEOAS) : 애플리케이션 상태는 하이퍼링크를 통해 전이되어야함 (Late binding) > 전이가 완료된 후에 다음으로 전이될 상태가 결정됨 = 링크는 동적으로 변경될 수 있어야함
오늘날 REST API는 대체로 3,4 번은 못 지키고 있음
무상태(Stateless) : 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
캐시 처리 가능(Cacheable): WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다. 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다.
계층화(Layered System): 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
Code on demand (optional) :서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다. (ex. 자바 애플릿, 자바스크립트)
클라이언트/서버 구조 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다
결론적으로 REST로 인해 웹의 독립적 진화가 가능해짐
HTTP에 지속적으로 영향을 줌
Host 헤더 추가 / 길이제한 다루는 방법 명시 (ex. 414 URI Too Long) / URI의 리소스 정의가 추상적으로 바뀜
REST API를 개발/ HTTP API를 개발/ (현재상태) 개발한 것을 그냥 REST API 라고 부르는것
현재 REST API를 구현하기 힘든 이유
WEB = 사람이 보는 것 , Media type = html, 하이퍼링크, self-descriptive (html 명세)
HTTP = 기계가 해석, Media type = Json, 하이퍼링크 X, non self-descriptive (key-val 정의 없음)
> Self-descriptive 해결하기 위한 노력
json에 미디어타입을 정의한 뒤 미디어타입 문서를 만들어 self description 정의 > IANA에 등록 (모든 미디어타입)
단점 : 매번 미디어타입 정의 필요
json에 명세한 문서 링크를 추가해 Profile 작성
단점 : 클라이언트가 Link 헤더(RFC 5988)와 profile (RFC 6906)을 알아야함.
GraphQL은 필요에 따라 REST API의 대안으로 원하는 컬럼만 요청이(POST) 가능하다
위처럼 타입 지정도 가능!
REST API vs GraphQL
• REST API - URI 마다 하는 작업/정보가 정해져있음 - 받아야 하는 항목이 많고 정해져있는 경우에 용이 - 필요에 따라 데이터 요청 시 요청 여러번 해야하는 경우 있음 ex) 반의 정보와 학생들 명단 > 두 번 요청해야 함 - 비동기적 코드는 한 번의 요청보다 복잡해짐
• GraphQL - 필요하지 않은 정보는 제외하고 body에 들어가는 정보로 유연하게 요청 가능 (구현 필요) - 다른 depth들의 정보도 한 번에 요청 가능 = 클라이언트 구현 편함
같은 API 서버를 쓰더라도 사용자/기기/상황마다 필요로 하는 정보가 다른 서비스에 용이하다
GraphQL 정보요청, 삽입, 수정 방식 = POST
결론 REST API : 요청 단순(URI), 데이터 복잡 GraphQL : 요청 복잡(bracket), 데이터 효율적