진정한 RESTful API 란 ?
클라이언트가 json 형태로 URL/B의 데이터를 받고싶다고 요청을 하면, 서버가 클라이언트가 원하는 타입 json형태로 B를 대표하는 상태로 응답한다.
REST란 심플하게 말해 http 메서드 4개를 이용하여 api를 디자인하는 것이라고 정의할 수 있지만, 사실 REST 라고 하는것은 서버 소프트웨어 아키텍처를 디자인할 수 있는 스타일을 의미한다. 웹서비스를 만들때 지켜야하는 가이드라인을 가지고 있는 스타일이라고 볼 수 있다.
RESTful 시스템 역사
HTTP는 1996년도부터 계속 개발이 되어오고 있는데, 이 때 활발하게 표준화 작업에 참여했었던 ‘Roy Fielding’ 이라는 양반이 박사 논문에
HTTP로 서버와 클라이언트간에 통신하는 일이 많아졌는데, 통신하는 것을 어떻게 조금 더 효율적으로 디자인할 수 있을까?
Roy Fielding
라고 고민하면서 , ‘네트워크 기반의 서버의 소프트웨어 아키텍처‘ 를 어떻게 효율적으로 만들지 고안해낸 것이 RESTful system이다.
REST API를 잘 만들기 위한 6가지 조건
- Client – Server architecture
- 서버는 클라이언트의 어플리케이션에 상관없이 데이터를 제공할 수 있는 아키텍쳐를 유지해야한다.
- Statelessness
- 하나의 요청이 다른 요청과 연결되는 state가 있는 상태가 아니라, state가 없는 상태로 서버를 디자인해야한다.
- Cacheability
- 캐싱 처리가 가능하다면, 캐시를 하는 것으로 디자인 해야한다.
- Layered System
- 클라이언트가 서버 사이 사이에 얼마나 많은 서버가 있던 지에 상관하지 않고, 서버에서 제공하는 API 하나로 공통된 자원을 제공해야 한다.
- Code on demand (option)
- 클라이언트가 원한다면, 클라이언트에서 수행해야하는 코드를 서버에서 클라이언트로 보내줄 수 있다.
- Uniform interface (가장 중요)
- Resource Identification in requests
- 클라이언트 요청에서 서버는 어떤 리소스를 원하는지 식별할 수 있어야 한다.
- 서버에 어떤 형태로 데이터가 저장되어있던, 응답은 클라이언트가 이해할 수 있는 포맷으로 전달되어야한다. (html , json..)
- Resource manipulation through representations
- 서버로부터 받은 해당 도메인을 대표할 수있는 state(data)를 통해서 해당 리소스에 대해서 어떻게 더 처리할 수 있는지에 대한 모든 정보를 알 수 있어야한다 (예를 들어, 서버로 부터 받은 정보를 통해서 앞으로 수정이나 삭제를 할때 어떤 식으로 요청을 할 수 있는지 알 수 있어야함)
- Slef-descriptive messages
- 서버에서 보내는 응답 데이터안에는 반드시 클라이언트가 이 데이터를 어떻게 처리해야하는지 설명 되어져있어야한다. (데이터 타입은 무엇인지 알려줘야함, Content-Type)
- Hypermedia as the engine of application state(HATEOAS)
- 서버에 url이 있다면, 클라이언트는 서버에 어떤 url들이 있는지 알아야되고 적절한 요청을 해야한다.
- Resource Identification in requests
HATEOAS
클라이언트가 accounts 관련한 GET 요청을 보냈을 경우, 서버에서는
그림과 같이 accounts에 대한 모든 액션들에 대해 어떤 url을 써야하는지, 어떤 url을 이용해서 서버에 요청할 수 있는지에 대한 정보를 보내줘야한다.
진정한 RESTful 시스템 규칙을 따라가는 서버를 만드려면 url을 잘 디자인하는 것 뿐만 아니라, 상기 이미지와 같이 모든 링크들을 클라이언트들에게 제공해줌으로써, 클라이언트가 서버에 어떤 url 이 있는지 일일이 찾아보거나 잘못 사용하지 않게해주는 것이 RESTful 시스템이다.
하지만 복잡하기때문에 네번째 Hypermedia 까지 고려하여 만드는 경우는 정말 흔치 않다. 😂
