REST API

---

REST

• Representational State Transfer
• 자원의 상태 전달 - 네트워크 아키텍처
• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE 등)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

---

REST의 구성 요소

1. 자원(Resource) : HTTP URI
2. 행위(Verb) : HTTP Method
3. 표현(Representations) : HTTP Message Pay Load

---

REST의 특징

1. Client, Server : 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 한다.
2. 무상태(Stateless) : 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.
3. Cache : 클라이언트는 서버의 응답을 cache(임시 저장)할 수 있어야 한다. 클라이언트가 캐시를 통해서 응답을 재사용할 수 있어야 하며, 이를 통해서 서버의 부하를 낮춘다.
4. 계층화(Layered System) : 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 확장할 수 있어야 한다.
5. ⬇️인터페이스의 일관성 : 인터페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하여, 클라이언트와 서버가 독립적으로 개선될 수 있어야 한다.
6. Code on Demand(Optional) : 자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로부터 클라이언트가 전달 받아 클라이언트에서 코드를 실행할 수 있어야 한다.

 

---

인터페이스의 일관성

다음의 인터페이스 일관성이 잘 지켜졌는지에 따라, REST를 잘 사용했는지 판단할 수 있다.

1. 자원의 식별
   - 웹 기반의 REST에서는 리소스 접근을 할 때 URI를 사용한다.
2. 메시지를 통한 리소스 조작
   - Web에서는 다양한 방식으로 데이터를 전달할 수 있다. 그 중에서 가장 많이 사용하는 방식은 HTML, XML, JSON, TEXT 등이 있다. 이 중에서 어떠한 타입의 데이터인지 알려주기 위해 HTTP Header 부분의 content-type을 통해 데이터의 타입을 지정해줄 수 있다. 또한 리소스 조작을 위해서 데이터 전체를 전달하지 않고, 이를 메시지로 전달한다. ---> client-server가 독립적으로 확장 가능하도록 한다.
3. 자기 서술적 메시지
   - 요청하는 데이터가 어떻게 처리되어야 하는지 충분한 데이터를 포함할 수 있어야 한다.
   - HTTP 기반의 REST에서는 HTTP Method와 Header 정보, URI에 포함되는 정보로 표현할 수 있다. 그 외에 담지 못한 정보들은 URI의 메시지를 통하여 표현한다.
4. 애플리케이션 상태에 대한 엔진으로서의 하이퍼미디어
   - REST API를 개발할 때 단순히 클라이언트 요청에 대한 데이터만 응답해주는 것이 아닌, 관련된 리소스에 대한 링크 정보까지 같이 포함되어야 한다.

---

 

REST API 설계 규칙

• Accept and respond wit JSON
• Use nouns instead of verbs in endpoint paths
• Name collections with plural nouns
• Nesting resources for hierarchical objects
• Handle errors gracefully and return standard error codes
• Allow filtering, sorting, and pagination
• Maintain Good Security Practices
• Cache data to improve performance
• Versioning our APIs

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

Best practices for REST API design

---