🔗 REST

✅ REST란?

• Representational State Transfer의 약자로 소프트웨어 프로그램 아키텍쳐의 한 형식.

• 자원을 이름으로 구분하여 해당 resource의 상태(정보)를 주고 받는 것을 의미.

• REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 대문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일.

✅ REST의 정의

HTTP URI를 통해 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE 등)를 통해
해당 자원에 대한 CRUD Operation을 적용하는 것을 의미.

• 웹 사이트의 모든 자원에 고유한 ID인 HTTP URI를 부여.
• CRUD Operation
  • Create : 생성 (POST)
  • Read : 조회 (GET)
  • Update : 수정 (PUT)
  • Delete : 삭제 (DELETE)
  • HEAD : header 정보 조회 (HEAD)

✅ REST의 구성요소

✔ 자원 (Resource) - URI
✔ 자원에 대한 행위 (Verb) - Http Method
✔ 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

• Resource : URI

  • 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재함.
  • 자원을 구별하는 ID는 'groups/:group_id'와 같은 HTTP URI 이다.
  • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청함.

• Verb : Http Method

  • HTTP 프로토콜의 Method(POST, GET, PUT, DELETE)를 사용.

• Representations : HTTP Message Pay Load

  • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보냄.
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 표현으로 나타내어질 수 있다.
  • JSON 이나 XML을 통해 데이터를 주고받는 것이 일반적.

✅ REST의 특징

Server-Client (서버-클라이언트 구조)

• REST Server와 클라이언트는 각각의 역할이 독립되어 의존성이 낮아야 함.
• 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 됨.
• REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임짐.
• Client : 사용자 인증이나 context(세션, 로그인 정보)등을 직접 관히라고 책임짐.

Stateless (무상태성)

• HTTP 프로토콜은 Stateless 프로토콜이므로 REST 또한 무상태성을 가짐.
• Client의 context를 Server에 저장하지 않음.
  • 세션, 쿠키같은 context 정보를 신경쓰지 않아도 되어 구현이 단순해짐.
• Server는 각각의 요청을 별개의 것으로 인식하고 처리.
• 각 API Server는 Client의 요청만을 단순 처리.

Cacheable (캐시 처리 가능)

• HTTP 프로토콜을 그대로 사용하기 때문에 캐싱 기능을 적용할 수 있음.
• 캐시 사용을 통해 응답시간이 빨라지고 RESR Server 트랩잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률 향상.

Layered System (계층형 구조)

• Client는 REST API 서버만 호출함.
• REST Server는 다중 계층으로 구성.
• 프록시, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.

Uniform Interface (인터페이스 일관성)

• URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행.
• 특정 언어나 기술에 종속되지 않고 HTTP 표준 프로토에 따르는 모든 플랫폼에서 사용 가능.

Code-On-Demand [optional]

• Server로 부터 스크립트를 받아서 Client에서 실행.

🔗 REST API

✅ REST API란?

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

• API : 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환 가능하도록 하는 것.

✅ REST API 설계 기본 규칙

1. URI는 정보의 resource를 표현해야함

• resource는 동사보다는 명사를, 대문자보다는 소문자를 사용.
• resource의 도큐먼트 이름으로는 단수 명사를 사용해야 함.
• resource의 컬렉션 이름으로는 복수 명사를 사용해야 함.
• resource의 스토어 이름으로는 복수 명사를 사용해야 함.

📍 리소스의 원형
✔ 도큐먼트 : 단일 정보를 포함하고 있는 데이터.
✔ 컬렉션 : 서버에서 관리하는 디렉터리라는 리소스.
✔ 스토어 : 클라이언트에서 관리하는 리소스 저장소.

2. resource에 대한 행위는 HTTP Method (POST, GET, PUT, DELETE 등)로 표현

• URI에 HTTP Method가 들어가면 안됨.
  • GET /users/delete/2❌ → DELETE /users/2⭕
• URI에 CRUD의 기능을 나타내는 행위에 대한 동사 표현이 들어가면 안됨.
  • GET /users/insert/2❌ → POST /users/2⭕
• 경로 부분 중 변하는 부분(세부 resource)은 유일한 값(id)으로 대체한다.
  • id = 2 인 user를 삭제하는 route:DELETE /users/2

✅ REST API 설계 세부 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용

• http://restapi.example.com/drink/coffee

2. URI 마지막 문자로 슬래시(/)를 포함하지 않음

• ❌ http://restapi.example.com/drink/coffee/ ❌

3. 하이픈(-)은 URI 가독성을 높이기 위해 사용

• http://restapi.example.com/drink/sugar-free

4. 밑줄(_)은 URI에 사용하지 않음

• ❌http://restapi.example.com/drink/sugar_free❌

5. URI 경로에는 소문자를 사용

• URI 경로에 대문자의 사용을 피한다

6. 파일 확장자는 URI에 포함하지 않음

• message body 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않고, Accept header를 사용한다.
• ❌http://restapi.example.com/drink/coffee/1/photo.jpg❌
• GET /drink/coffee/1/photo HTTP/1.1 Host: restapi.example.com
Accept: image/jpg

7. 리소스 간 연관관계 표현

• /리소스명/리소스ID/관계가 있는 다른 리소스명
• GET users/{userid}/orders (일반적으로 소유 관계 표현할 때 사용)

🔗 RESTful

✅ RESTful이란?

• REST라는 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어.
• REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다.

✅ RESTful의 목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
• RESTful한 API를 구현하는 근본적인 목적은 성능 향상이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것.

💛 참고 :
https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://dodop-blog.tistory.com/272
https://zsgg.tistory.com/entry/REST-API-%EB%94%94%EC%9E%90%EC%9D%B8-%EA%B7%9C%EC%B9%99