REST

REST (REpresentational State Transfer)는 모든 서버 자원들에 대한 고유 주소(URI)를 지정하고 HTTP Method를 통해 자원에 대한 상태를 정의하는 소프트웨어 아키텍쳐입니다.

HTTP Method

HTTP Method에는 여러가지가 있지만 가장 대표적인 5가지 메소드는 다음과 같습니다.

method	설명
POST	생성, 자원을 생성하거나 작업 처리를 요청.
GET	조회, 특정 자원의 상태나 정보를 요청.
PUT	전체 수정, 자원의 상태를 요청한 데이터로 전체 수정(덮어쓰기) 요청.
PATCH	부분 수정, 자원의 일부분 수정 요청.
DELETE	삭제, 자원을 서버에서 삭제 요청.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods
에서 더 많은 methods를 확인하실 수 있습니다.

HTTP 포스트에서 HTTP에 대한 더 많은 내용을 다루고 있으니 필요 시 참조 부탁드립니다.

REST 원칙

REST 아키텍쳐를 설계하기 위한 6가지 원칙을 REST 원칙이라고 부릅니다. 이 6가지 원칙을 잘 지켜 설계된 REST API를 "RESTful하다"라고 표현합니다.

1. Client-Server 구조

클라이언트와 서버의 역할을 명확하게 분리하라는 원칙입니다.

• 클라이언트
  클라이언트는 사용자 인터페이스, 사용자 인증 등 사용자 정보 관리에 집중합니다.
• 서버
  서버는 API 제공, DB 관리 등의 비즈니스 로직 처리에 집중합니다.

명확하게 분리함(의존하지 않음)으로서 클라이언트-서버가 각자 독립적으로 구성, 확장할 수 있습니다.

2. Stateless

Stateless (무상태성)은 서버가 클라이언트의 이전 요청이나 콘텍스트를 따로 저장/관리하지 않는 원칙입니다.

클라이언트가 보내는 모든 요청은 서버가 해당 요청을 처리하는데 필요한 모든 정보를 가져야합니다. 이는 서버가 클라이언트의 이전 요청/콘텍스트를 저장하지 않기 때문에 필요한 과정입니다.

또한 이전 정보를 따로 저장/관리하는 로직이 필요없어지므로 구현 및 구조가 간단해지는 특성을 갖습니다.

3. Cacheable

Cacheable (캐시 처리 가능)은 HTTP의 캐싱 기능을 적용할 수 있어야하는 원칙입니다.

응답 시 자신이 캐시 가능한지 아닌지 명시합니다. 캐시가 가능할 때 클라이언트는 캐시된 데이터를 재활용하여 서버와 불필요한 요청-응답을 거치지 않게되어 응답 속도가 상승하고 서버는 반복적인 요청 처리를 하지 않게됨으로서 확장성 증가/부하 감소 효과를 얻습니다.

4. 계층 구조 아키텍쳐

클라이언트는 서버와의 통신 내용을 알 수 없어야하고 알 필요도 없도록 다계층으로 설계되는 원칙입니다.

비즈니스 로직을 처리하게되는 서버의 API의 앞에 보안, 암호화, 캐시 등을 두어 다계층 구조로 구성할 수 있습니다. 이 과정에서 클라이언트는 비즈니스 로직을 직접처리하는 서버와 통신하는 지 그 앞 단의 다른 계층과 통신하는지 알 수 없으며, 알 필요도 없습니다. 오직 요청에 대한 응답만 받아서 반환합니다.

5. 인터페이스 일관성

고유 주소로 정의된 자원(URI)을 조작하는 인터페이스 전반적인 시스템에 걸쳐 일관성을 가져야합니다.

일관성을 가기지 위해 다음 네 가지 조건을 준수해야합니다.

• 자원 식별: URI만을 통해 어떤 자원에 대한 요청인지 명확하게 식별 가능해야한다.
• 표현과 자원 조작: 클라이언트는 자원을 조작할 때 표현(JSON 등)과 HTTP 메소드를 통해 조작야한다.
• 자기 서술 메시지: 요청/응답 메시지만 보고도 내용을 이해할 수 있어야한다.
• HATEOAS (Hypermedia As The Engine Of Application State): 응답에 현재 상태에서 할 수 있는 다음 Action들의 링크를 포함해 클라이언트 측에서 애플리케이션의 상태를 동적으로 탐색할 수 있게 해야한다.

6. Code on Demand

Code on Demand는 여섯 가지 원칙 중 유일하게 Optional한 사항입니다.

대부분의 상황에서 REST API는 정적 리소스를 통신하지만, 일부 특수 상황에서 실행 가능한 코드(JavaScript 등)를 전송할 수 있습니다. 이때 실행 가능한 코드는 반드시 요청 시에만 실행할 수 있도록 해야하니다.

이 원칙이 선택 사항인 이유는 REST API의 주 사용 목적(데이터 전송)과는 거리가 있고 실행 가능한 코드가 가지고 있는 보안적 위협, 구조가 복잡해지는 문제 등으로 인해 잘 선택되지 않는 방식이기 때문입니다.

---

REST API

REST API는 REST 원칙을 지켜 설계한 API를 의미합니다.

3가지 핵심 구성 요소

REST API는 세 가지 핵심 구성 요소를 갖습니다.

• 자원 URI: 자원은 URI로 표현되며, 처리하고자 하는 데이터(객체)를 의미합니다. 사용되는 모든 자원들이 고유한 URI를 갖고 식별됩니다.
• 행동 HTTP Method: 자원에 대해 수행할 행동(주로 CRUD)이며, HTTP 메소드를 사용합니다.
• 표현 Payload: 클라이언트-서버가 데이터를 주고받는 형식입니다. XML, JSON 등이 사용됩니다. (현대에는 주로 JSON을 사용)

좋은 REST API 설계 규칙

좋은 REST API 설계를 위한 규칙은 다음과 같습니다.

URI는 자원을 포함

• 자원은 소문자를 사용해서 표현
• 복수형 명사를 사용 (동사는 사용하지 않음)
• Collections는 복수형으로 작성

요청/응답은 HTTP 메소드로 표현

• HTTP 메소드를 사용하되, URI에 HTTP 메소드가 포함되지 않을 것
• 행동에 대한 동사 표현을 넣지 않음
• id 값을 이용해 유일한 식별자 값을 사용

/, - 사용

• /는 계층 관계를 나타낼 때 사용
• -는 띄어쓰기를 대체해 가독성 향상 목적에만 사용
• _는 사용하지 않음
• URI 마지막에 /를 사용하지 않음

URI 작성

• URI는 소문자로만 작성
• 파일의 확장자명은 생략

HTTP Status Code 반환

요청에 대한 성공/실패 여부를 적절한 HTTP Status Code로 반환해주어야 합니다. 대표적인 HTTP 상태 코드는 다음과 같은 것들이 있습니다.

Code	설명
200 OK	요청 성공
201 Created	자원 생성 성공
400 Bad Request	잘못된 요청
401 Unauthorized	인증되지 않은 사용자
403 Forbidden	접근 권한 없음
404 Not Found	요청 자원이 없음
500 Internal Server Error	서버 오류

더 많은 상태 코드와 설명은 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods 에서 확인하실 수 있습니다.