RESTful API

RESTful API

• API의 다양한 형식들 중 오늘날 가장 널리 사용되는 것
• A가 어떤 방식으로 요청하고 B가 어떤 방식으로 응답할 지 지정해 놓은 다양한 형식들 중 하나
• Create, Read, Update, Delete 이 4가지 작업을 위한 요청들을 RESTful한 요청으로 작성해보면 POST, GET, PUT, PATCH, DELETE 이다.
  Create --- POST https://api.haha.com/v1/books
  Read ----- GET https://api.haha.com/v1/books
  ----- GET https://api.haha.com/v1/books/1
  Update --- PUT https://api.haha.com/v1/books/20
  --- PATCH https://api.haha.com/v1/books/7
  Delete --- DELETE https://api.haha.com/v1/books/123
• HTTP는 RESTful API의 필수요소는 아니지만 RESTful API의 조건을 구현하기 용이하기 때문에 주로 사용됨
• 조회, 수정, 삭제 모두 books라고만 되어 있고 뭘 하는지 안적혀 있어서 구분이 안감
  --> URI는 이 요청이 '어떤 자원'에 관한 것인지 표현해야 하고 또 가능한 한 '그것만' 표현해야 함(RESTful API에서 중요한 원칙)
  --> 이 요청들이 도서관의 책들에 관한 것임을 알 수 있고 책들 중 특정 책에 대한 요청인 경우에는 이처럼 다른 책들과 중복되지 않는 색인번호를 뒤에 붙여서 명시함

RESTful API에서 권장되는 또 다른 원칙 HATEOAS

• Hypermedia
• As
• The
• Engine
• Of
• Application State

Status Code

• 2XX Success
• 4XX Client Error
• 5XX Server Error

RESTful API의 또 다른 특성

• Stateless: '상태가 없는' 통신
  -> 클라이언트의 상태 정보가 서버에 저장되지 말아야 한다는 것(서버는 클라이언트에 대해 아무것도 기억하지 말아야 한다는 것)
  -> 클라이언트의 요청은 몇 번째 반복되든 필요한 모든 내용을 포함하고 있어야 함
• Idempotent(멱등성)
  -> 클라이언트가 같은 요청을 몇 번을 보내든 언제나 같은 답이 돌아와야 함(실제 데이터가 바뀌었을 때는 제외)
• Cacheability
  -> 클라이언트에서 어떤 요청에 대한 응답을 캐싱해 두면 같은 데이터가 필요할 때마다 요청을 보내지 않아도 됨
  -> 서버도 특정 요청에 대해 응답한 바를 기억해 두면 다른 클라이언트가 같은 요청을 보냈을 때 또 데이터베이스에서 정보를 캐낼 필요 없이 갖고 있는 걸 바로 보내면 됨