RESTful API

RESTful 한 API, REST의 특징과 규칙을 지키는 API
공통적으로 규칙을 정해두어 협업, public api 사용 등과 같이 restful api를 사용시 따로 학습 코스트를 들이지 않아도 된다.

RESTful API 규칙

• URI에서는 어떤 자원에 관한 것인지만 표현해야 한다
  /users -> users에 관한 api
• 어떤 작업을 하는지에 대한 동사는 포함하지 않는다
  /users/get -> get (x)
• HTTP 메소드로 어떤 종류의 작업을 하는지 표현한다 (POST, GET, PUT, PATCH, DELETE)
• 쿼리 파라미터로 조건을 지정할 수 있다 (페이징 정보)
• 특정 데이터를 받고 싶을때 끝에 고유 식별자를 넣어준다 (/books/1) → 1번 책
• 하위 항목이 있다면 그 뒤에 붙인다 (books/1/reviews)
  → 리소스들이 서로 어떤 관계를 갖는지 URI를 통해 쉽게 파악할 수 있음

• HATEOA (Hypermedia As The Engine Of Application State)
  → 각 요청의 응답에 사용가능한 다른 요청의 정보를 포함 시킨다 (update, delete..)
  

HTTP 메소드

• GET - 데이터의 정보를 가져온다
• POST - 데이터 추가
• PUT - 데이터 업데이트 (데이터 전체)
• PATCH - 데이터 일부 업데이트
• DELETE - 데이터 삭제

특징

Stateless (무상태)

상태가 없는 통신, 클라이언트의 상태 정보는 서버가 저장하지 않아야 합니다.
즉, 클라이언트 요청시 매번 필요한 정보를 줘야 합니다. 서버는 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.

• 서버의 확장성 고려, 연관되어 있다면 확장 어려움

Idempotent (균일한 인터페이스)

동일한 리소스에 대한 모든 API 요청은 요청의 출처에 관계없이 동일하게 표시되어야 합니다.

Cacheability (캐시 가능성)

서버와 클라이언트 간에는 정보를 저장하지 않아야하지만, 자기가 어떤 응답을 보냈는지 어떤 응답을 받았는지는 기억해야 합니다.

캐싱 - 요청에 대한 응답을 캐싱해두면 같은 요청 여러번 보낼 필요 없고, 같은 요청에 대해서는 캐싱해둔 데이터만 보내면 되어 응답에 대한 리소스를 아낄 수 있습니다.