REST API

REST API

(Representational State Transfer Application Programming Interface)

애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙.
REST **6가지** 디자인 원칙 (아키텍쳐 제한사항)

• 인터페이스 일관성 (Uniform Interface):
  서버의 인터페이스는 일관성 있게 설계되어야 한다.
  REST API는 통일된 인터페이스 규칙을 따르며, 클라이언트는 이를 이해하고 활용할 수 있다.
  이는 서비스의 가시성과 재사용성을 향상시키는데 도움을 준다.

• 클라이언트-서버 구조 (Client-Server):
  클라이언트와 서버는 독립적으로 개발되어야 한다.
  클라이언트는 사용자 인터페이스와 사용자 상호작용을 처리하고, 서버는 데이터 저장, 처리, 보안 등의 역할을 수행한다.
  이렇게 분리함으로써 각각의 역할과 책임을 명확히 할 수 있다.
  

• 상태 없음 (Stateless):
  서버는 클라이언트의 상태를 저장하지 않는다.
  각각의 요청은 독립적으로 처리되며, 클라이언트는 필요한 상태 정보를 모두 제공해야 한다.
  이렇게 함으로써 서버는 확장성이 높아지고, 클라이언트와의 상호작용이 단순해진다.
  

• 캐시 (Cacheable):
  서버는 응답을 캐싱할 수 있도록 허용해야 한다.
  클라이언트는 이전에 받은 응답을 캐시하여 동일한 요청에 대한 응답을 서버로부터 다시 받지 않아도 된다.
  이는 네트워크 성능을 향상시키고 서버 부하를 줄일 수 있다.
  

• 계층화 (Layered System):
  서버와 클라이언트 사이에 중간 계층을 추가하여 구조를 확장할 수 있다.
  클라이언트는 중간 계층과 상호작용하며, 중간 계층은 클라이언트의 요청을 서버에 전달하고 응답을 클라이언트에게 반환함으로써 클라이언트와 서버 간의 직접적인 의존성을 줄이고, 각각의 역할과 책임을 명확히 할 수 있다.
  이를 통해 확장성과 보안성을 개선할 수 있다.
  

• 자체 표현 (Self-descriptive):
  리소스의 표현은 자체적으로 이해 가능해야 한다.
  응답은 자체적으로 리소스를 설명하는 메타데이터를 포함해야 하며, 클라이언트는 이를 통해 리소스와 상호작용할 수 있다.
  이는 확장성과 호환성을 향상시키는데 도움을 줍니다.
  

이러한 REST 디자인 원칙을 따르면 API가 유연하고 확장 가능하며, 다양한 클라이언트와 통신할 수 있는 표준화된 인터페이스를 제공할 수 있다.

REST API의 작동 방식

• HTTP method: REST API는 HTTP method를 사용하여 서버에 요청을 전달한다.
  ex)

  GET: 리소스의 조회 요청.
  POST: 새로운 리소스를 생성하기 위해 데이터를 서버로 제출.
  PUT: 기존 리소스를 업데이트.
  DELETE: 리소스 삭제.

• 리소스: REST API는 리소스 중심으로 동작.
  일반적으로 URI로 식별되며, 예를 들어 '/users', 'propducts'와 같은 형식이 될 수 있다.

• 표현 형식: 리소스의 상태는 다양한 형식으로 표현된다.
  ex_ JSON, XML, HTML 등 .. JSON형식이 많이 사용된다.

• 요청과 응답: client는 HTTP요청을 보내고 서버는 해당요청에 대한 응답을 반환한다. 요청은 URI, 헤더, 매개변수 등의 정보를 포함하며, 응답은 상태 코드,. 헤더 데이터 등의 정보를 포함한다.

• 헤더와 매개변수: 요청 헤더와 매개변수는 메타데이터, 권한 부여, 캐싱, 식별자 정보 등을 포함한다. 이러한 정보는 API 호출에서 중요한 역할을 한다.

client와 서버 간의 상호작용을 가능하게 하며 일관성, 확장성, 호환성, 보안, 성능 등을 고려하여 디자인되어야 한다. REST API는 웹 사이트와 유사한 HTTP 기능을 갖춘 데이터베이스 기능을 수행한다.