REST, REST API

REST

REST (Representational State Transfer)는 WWW와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처중 하나의 형식이다.
REST는 Web이 가지고 있는 기술, HTTP 프로토콜을 그대로 활용한다.
자원의 명시를 HTTP URI (Uniform Resource Identifier)를 통해 명시하고,
HTTP Method를 통해 해당 자원에 CRUD Operation을 적용하는 것을 의미한다.

HTTP Method

• GET : 리소스 조회
• POST : 리소스 등록
• PUT : 리소스 수정
• DELETE : 리소스 삭제

CRUD Operation

• Read : 조회 (GET)
• Create : 생성 (POST)
• Update : 수정 (PUT)
• Delete : 삭제 (DELETE)

REST를 사용하는 이유

• 인터페이스 표준화 : HTTP Method 사용으로 인해 클라이언트와 서버 간의 상호작용이 표준화되고 일관성이 유지된다.
• 유연성 및 확장성 : PC환경이 아닌 모바일 앱 등에서도 사용이 가능하며, 새로운 기능 추가가 상대적으로 간단하다.
• 무상태성 : 각 요청의 상태를 유지하지 않기 때문에, 서버가 요청을 독립적으로 처리할 수 있어 확장성과 안정성이 높다.
• 응답 캐시 가능 : 응답을 캐시로 가질 수 있기 때문에 네트워크 사용량을 줄이고, 클라이언트 성능을 높힐 수 있다.
• 계층화된 구조 : 클라이언트와 서버 사이에 프록시나 게이트웨이등의 중간 계층을 허용해 확장성, 보안성을 높힐 수 있다.

REST의 장점

1. 간단한 설계 : HTTP URI, HTTP Method로 자원을 표현하고 작업을 정의하기 때문에 API 설계가 간단명료하다.
2. 유연한 데이터 형식 : JSON, XML, HTML등 다양한 데이터 형식을 지원하므로, 클라이언트와 서버의 데이터 교환이 유연하다.
3. 확장성과 성능 : 무상태성, 캐시가 가능한 점등 때문에 서버의 확장성과 성능이 향상된다.
4. 범용성 : 다양한 플랫폼과 언어에서 사용할 수 있고, 클라이언트와 서버간의 독립성이 보장된다.
5. 표준화된 프로토콜 : HTTP 기반이기 때문에, 표준 프로토콜을 사용하여 상호 운용성이 보장된다.

REST의 단점

1. 과도한 상호작용 : 무상태성을 유지하려면 클라이언트 요청에 모든 정보가 포함되어있어야 하므로, 네트워크 사용량이 높아질 수 있다.
2. 복잡한 쿼리 : 복잡한 쿼리문이나, 필터링과 같은 작업 지원에 한계가 있을 수 있다.
3. 표준 미비 : REST는 정해져 있는 프레임워크같은게 아닌, 아키텍쳐 스타일이기 때문에, 구체적인 구현 방법이 표준화 되어있지 않다.

REST API, RESTful

REST 라는 아키텍쳐 스타일을 따르는 Application Programming Interface (API)이다.
REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있으며, 공식적인 명칭은 아닌 일반적으로 칭하는 용어이다.

REST API를 설계하기 위해선 다음과 같은 규칙이 있다.
1. "/"는 계층 관계를 나타내기 위해 사용한다.
2. URI의 마지막에는 "/"를 붙히지 않는다.
3. 부득이하게 URI가 길어진다면 "-"으로 가독성을 높힌다.
4. "_"은 사용하지 않는다.
5. URI 경로에 대문자 사용을 자제한다.
6. 파일확장자명은 URI에 포함하지 않는다.
7. 리소스 간에 연관관계가 있는 경우 (Has) "리소스명/리소스ID/관계 있는 다른 리소스명"과 같이 표현한다.

모든 규칙은 무조건적으로 지켜져야 하는 강제사항이 아니지만 , RESTful한 API를 구축하기 위해선 권장되는 목표이다.