REST API 란?

Representational State Transfer API
(*API : 클라이언트와 데이터베이스 사이의 접점)

• 자원을 설명으로 구분하여 해당 자원의 상태를 주고받는 모든것을 의미한다
• API 시스템을 구현하기 위한 다양한 아키텍처 중 가장 널리 사용되는 형식이다 (REST, GraphQL, SOAP 등 많은 API시스템이 있다)

REST

클라이언트가 유저의 정보를(WHAT) 가져오고자 요청(HOW)하는것

• HTTP URL을 퇑해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 요청을 처리하도록 설계된 아키텍쳐를 의미한다

REST API 역사

• 로이 필딩(Roy Thomas Fielding) : HTTP 개념 설립의 주요 저자중 한 사람
• HTTP를 만들었지만

REST API 장점

• Self-descriptiveness : API의 목적이 쉽게 이해가 된다 GET https://10.58.4.1/products
• client-server 분리와 함께 발달 하여 개별 부분의 발전에 있어 다른 부분이 영향을 주지 않는다

REST API 단점

• 표준 규약이 없어 안티 패턴으로 작성되는 경우가 흔함 /products/all 통신이 안되는건 아님

RESTful API란?

REST의 규칙을 지켜서 만든 API를 뜻한다. (REST란 소프트웨어 프로그램 아케텍처의 한 형태)

성능의 향상 보다는 규칙을 통한 API이해도와 호환성을 높이기 위함이다.
(유지보수 및 코드의 재사용성에 용이)

RESTful API 설계 원칙

1. Uniform Interface *가장중요

• 구성요소(클라이언트와 서버 등) 사이의 인터페이스는 일관 돼야 한다는 원칙
  • 플랫폼에 무관하며, 특정 언어나 기술에 종속 받지 않는 특징을 의미
• URL는 동사를 제외한 명사로 구성 [GET]/find/users/1 -> [GET]/users/1
• Resource에 대한 행위를 HTTP method 만으로 표현 [POST]/post/reviews -> [POST]/reviews
• Resource 사이에 연관 관계 및 계층 관계가 있는 경우 / 사용 (자명한 엔드포인트)
  • [GET]/users/{luser_id}/posts
• URL 마지막 문자로 / 포함하지 않음
• URL가 길어지는 경우 -을 사용하여 가독성을 높임 (하이퍼링크)
  • [GET]/users/1/ordered-itmes
• 파일 확장자는 URI에 포함 시키지 않고 파일의 확장자는 header에 포함된다

2. 나머지 원칙들

• Client - Server : 구조를 단순화 시키고 작은 단위로 분리함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 한다
• Stateless : 각 요청 간 클라이언트의 Context가 서버에 저장되어서는 안된다
• Cacheable : 클라이언트는 요청에 관한 응답을 따로 저장함으로써 추후에 재사용이 가능하게 한다
• Layered System : 클라이언트는 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다
• Code on demand : 서버가 네트워크를 통해 클라이언트에 전달한 javascript등과 같은 프로그램들은 그 자체로 실행될수 있어야 한다