REST API

REST (Respresentational State Transfer)

웹 API를 구축하는 방법에 대한 일련의 규칙 및 지침
요청과 응답에 관해 지정해 놓은 다양한 형식들 중 하나

즉, HTTP Method(POST, GET, PUT, DELETE, PATCH)를 통해 자원을 처리(CRUD)하도록 설계된 아키텍쳐를 말함

CURD Operation

CREATE : 데이터 생성 (POST)
READ : 데이터 조회 (GET)
UPDATE : 데이터 수정 (PUT, PATCH)
DELETE : 데이터 삭제 (DELETE)

REST의 구성요소

• 자원 (Resource) : HTTP URI
  • 모든 자원에는 고유한 ID가 서버에 존재함
  • 자원을 구별하는 ID = HTTP URI
  • 클라이언트는 URI를 이용해 자원 지정하고, 해당 자원의 상태에 대한 조작을 서버에 요청
• 행위 : HTTP Method
  • HTTP의 프로토콜은 Method를 사용
  • GET, POST, PUT, DELETE와 같은 메서드 제공
• 표현
  • 클라이언트의 요청에 대하여 서버는 적절한 응답을 보냄
  • 응답에는 JSON, XML, TEXT등 여러 형태가 있음

---

REST 설계 원칙 (아키텍쳐 제약 조건)

1. 균일한 인터페이스 ( Uniform Interface )
   동일한 리소스에 대한 모든 API 요청은 동일하게 표시되어야 함
   요청된 리소스는 식별 가능해야 함
2. 클라이언트 - 서버 아키텍쳐
   클라이언트, 서버, 리소스로 구성되어 있고, 요청이 HTTP를 통해 관리됨. 역할이 명확히 분리된다는 특징
3. 무상태성 ( Stateless )
   클라이언트 요청과 관련된 데이터를 서버에서 따로 저장, 관리하지 않음
4. 캐시 가능성
   리소스의 캐시 가능. 서버 응답에 전달된 리소스에 대해 캐싱 허용 여부가 포함되어야 함
   
5. 계층화된 시스템 아키텍처
   호출과 응답이 서로 다른 계층을 가짐
6. 코드 온디맨드 (선택)
   REST API는 보통 정적 리소스를 전송하지만, 때에 따라 응답에 실행 가능한 코드를 전송해 클라이언트 기능을 확장

---

REST API

REST를 기반으로 서비스 API를 구현한 것

특징

• REST 기반으로 시스템을 분산해 확장성, 재사용성을 높여 유지보수 및 운용을 편리하게 함
• 다양한 언어를 통해 클라이언트 제작 가능

설계 규칙

1. 명사, 소문자 사용 / 동사 X
2. 명사는 복수형으로
3. URI 마지막에 / 포함 X
4. URI는 언더바 사용 X / 하이픈 O
5. 파일 확장자 표시 X

---

RESTful API

REST스러운, REST다운,
즉, REST라는 특성을 가진 웹 서비스를 RESTful 하다고 할 수 있음

(RESTful한 웹 서비스가 모두 REST인 것은 아님 !!)

목적

일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것
성능 향상에 초점 X

---

URI와 URL 차이

URI = 식별자

• 리소스를 식별하는 일반적인 용어

URL = 식별자 + 위치

• URI의 하위 개념
• 클라이언트가 서버에 특정 자원 요청시 사용되는 문자열. 특정 리소스의 위치를 지정함

ex)
https:// www.example.com/index.html

프로토콜 : https://
호스트 주소 : www.example.com
자원 경로 : index.html

= HTTPS 프로토콜 사용해 "http://www.example.com" 서버에 있는 index.html 파일을 요청하는 것

---

[참고]

https://www.ibm.com/kr-ko/think/topics/rest-apis
https://wikidocs.net/blog/@dragonhappy9/1262/