api = > 인터페이스
서버입장에서 api => 클라이언트가 사용할수있는 url
restful => rest의 성격(규약)을 지닌
=> 대표할수있는 상태를 전송하는
서버에는 다양한 데이터 존재
이데이터들을 url 형태로 클라이언트에게 제공
클라이언트 "나는 json 데이터를 받고싶어!"
서버 "json 형태를 대표하는 형태로 보내준다"
rest : 서버 소프트웨어 아키텍처 디자인 스타일 (가이드 라인을 가지고있다)
6가지 가이드
1.클라이언트 - 서버 아키텍처를 가져야한다
2.statelessnsess : 하나의 요청이 다른요청과 연결 되지 않아야한다
3.casheability : 캐쉬를 할수있는것으로 디자인 해야한다
4.layered system : 공통된 api 하나로 뒤에 서버가 얼마나 있든지 상관하지 않고 하나의 api 를 사용하 도록 레이어드 시스템을 만들어야한다
5.code on demand
6. ⭐️ uniform interface :
🖍 statelessness , cacheability 는 http 에서 얻어갈수있는 특징이다
⭐️ uniform interface :
1. 클라이언트 요청에대해 서버에 있는 데이터를 식별할수 있어야함
서버에 어디에 있든(관리하든) 클라이언트가 이해할수있는 (html,json..) 형식으로 보내줘야함
2. 서버로 부터 받은 해당도메인을 대표할수 있는 (state)형태로
해당리소스에대해서 어떻게 처리할수있는지에 대한 모든정보를 알수있어야한다
ex) 서버로 부터 받은 데이터를 통해서 그해당 리소스에 대한 앞으로 수정이나 삭제할때
어떤식으로 요청을 할수있어야하는지 알수있어야 한다
🖍 restApi 는 url 디자인 ? => no! url 디자인 + 외적인 것을 처리해야함
3.서버에서 보내는 응답데이터 안에는 클라이언트가 어떻게 처리해야하는지 담겨 있어야한다
4.HATEOAS : <클라이언트 측에서 신경써서 서버에 요청을 해야한다 >