REST ,

REST (Representational State Transfer) 의 약자 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다.

API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있습니다. REST 아키텍처 스타일을 따르는 API를 REST API라고 합니다. REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 합니다. RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타냅니다. 하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있습니다.

---

REST-API 는 세가지 요소로 구성된다.

• 리소스 : 리소스(자원) 은 HTTP URL로 표현한다.
• 행위 : 리소스에 대한 행위는 HTTP 메서드로 표현한다. 일반적으로 리소스를 생성하고 값을 조회, 수정, 삭제 하는 행위 등을 표현 할 수 있다.
• 표현 : 리소스에 대한 행위 내용은 HTTP 메시지 내용으로 표현한다. HTTP 메시지의 포맷은 JSON을 사용한다.

세 가지 요소를 사용하여 REST-API를 설계할 때는 다음 기본 규칙을 준수한다.

• 리소스 이름은 가능하면 동사보다 명사를 사용한다.
• 리소스는 계층적 구조를 가질 수 있다. 계층 관계를 가지므로 복수 형태로 사용한다.
• 리소스에 대한 행위는 GET, POST, PUT, DELETE 를 기본으로 한다. 때에 따라서는 PATCH 를 사용한다.

---

REST-API는 리소스에 대한 행위를 HTTP 메서드를 기준으로 설계한다. 그래서 리소스를 동사로 설계하면, 행위가 중복되므로 의미가 모호해 질 수 있다. 보통 네 개나 다섯 개의 HTTP 메서드를 이용하면 리소스에 대한 행위를 정의한다.

---

설계자 의도에 따라 GET, POST, PUT, DELETE 등 네 개의 HTTP 메서드 외에 PATCH 메서드를 추가해서 사용한다.

• GET
  • 리소스 정보를 조회하는 데 사용한다. 리소스가 복수형이면 리스트 객체를 응답하고 단수형이면 단수 객체를 응답한다.
• POST
  • 클라이언트가 HTTP 메시지 바디에 전송한 데이터를 정의된 리소스에 생성한다.
• PUT
  • 정의된 리소스 객체를 HTTP 메시지 바디에 전송한 데이터로 전체 수정한다.
• DELETE
  • 정의된 리소스를 삭제한다.
• PATCH
  • 정의된 리소스의 일부 데이터를 수정한다.

---

---

REST-API 의 특징

• Server-Client(서버-클라이언트 구조)
• Stateless(무상태)
• Cacheable(캐시 처리 가능)
• Layered System(계층화)
• Uniform Interface(인터페이스 일관성)

REST-API 의 의 장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.

• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.

• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.

• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.

• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.

• 서버와 클라이언트의 역할을 명확하게 분리한다.

REST-API 의 의 단점

• 표준이 존재하지 않는다.

• 사용할 수 있는 메소드가 4가지 밖에 없다.HTTP Method 형태가 제한적이다.

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.

• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.