[CS] Rest 와 Restful API

✔️Rest란?

**REST(Representational State Transfer)**는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개된 소프트웨어 아키텍처 스타일입니다. REST는 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일로, 웹 기반의 분산 시스템을 설계하는 데 사용됩니다.

 

💡Rest의 특징

• 자원(Resouces) 기반의 URI: 모든 자원은 고유한 URI로 표현되며, 이 URI를 통해 자원에 접근합니다.
• HTTP 메소드 활용: HTTP 메소드(GET, POST, PUT, DELETE 등)를 활용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행합니다.
• 자기 표현적 메시지: 클라이언트와 서버 간의 통신은 자기 표현적인 메시지를 통해 이루어져야 합니다. JSON 또는 XML 형식으로 데이터를 주고받는 것이 일반적입니다.
• 무상태(Stateless): 각 요청은 서버에 저장되지 않고, 필요한 모든 정보는 요청 자체에 포함되어야 합니다.
• 캐싱 가능(Cachable): 클라이언트는 응답을 캐시하여 나중에 동일한 요청에 대해 저장된 응답을 사용할 수 있습니다.
• 계층화(Layered System): 서버와 클라이언트 사이에 여러 계층(로드 밸런서, 게이트웨이 등)을 둘 수 있습니다.

✔️Restful API란?

RESTful API는 REST 아키텍처 스타일을 따르는 API를 말합니다. 이는 웹 개발에서 널리 사용되는 API 디자인 스타일 중 하나로, 클라이언트와 서버 간의 통신을 위한 표준화된 방법을 제공합니다.

 

💡Restful API의 설계원칙

• URI 설계: 자원을 명사형으로 표현하고, 동사보다는 HTTP 메소드로 행위를 나타냅니다.
• HTTP 메소드 활용: GET은 데이터 조회, POST는 데이터 생성, PUT은 데이터 수정, DELETE는 데이터 삭제 등에 사용됩니다.
• 스테이터스 코드: 적절한 HTTP 스테이터스 코드를 사용하여 응답의 상태를 나타냅니다.
• 표현 형식: 데이터 포맷은 주로 JSON을 사용하며, 클라이언트가 원하는 데이터 형식을 Accept 헤더로 지정할 수 있습니다.
• 버전 관리: API의 변화에 대비하여 버전을 관리하고, 이전 버전과의 호환성을 유지해야 합니다.

💡Restful API의 설계예시

예를 들어, 블로그 포스트를 다루는 RESTful API를 설계한다고 가정.

 

1. 포스트 목록 조회: GET /posts
2. 특정 포스트 조회: GET /posts/{post_id}
3. 포스트 생성: POST /posts
4. 포스트 수정: PUT /posts/{post_id}
5. 포스트 삭제: DELETE /posts/{post_id}

 

💡Rest와Restful API의 장점

• 간결하고 일관된 디자인: RESTful API는 자원 기반의 URI와 HTTP 메소드를 활용하여 간결하고 일관된 디자인을 제공합니다. 이로써 API의 구조를 쉽게 이해하고 사용할 수 있습니다.
• 유연한 클라이언트-서버 아키텍처: REST 아키텍처는 클라이언트와 서버 간의 분리를 강조하며, 서버의 변경이나 확장이 클라이언트에 영향을 미치지 않도록 합니다.
• 가독성과 확장성: RESTful API는 HTTP 메소드와 URI를 활용하여 의미 있는 리소스 경로를 생성하므로 가독성이 높습니다. 또한, 새로운 리소스 및 기능을 추가하기 쉽습니다.
• HTTP 프로토콜의 활용: RESTful API는 기존의 HTTP 프로토콜을 활용하므로 HTTP 기능(캐싱, 헤더, 스테이터스 코드 등)을 활용하여 성능을 향상시킬 수 있습니다.
• 클라이언트 측 캐싱: 클라이언트는 응답을 캐시하여 동일한 요청에 대한 성능을 향상시킬 수 있습니다.
• 다양한 클라이언트 지원: RESTful API는 다양한 종류의 클라이언트(웹 브라우저, 모바일 앱 등)와 호환되어 플랫폼 간 상호 운용성을 쉽게 구현할 수 있습니다.

💡Rest와Restful API의 단점

• 표준 부재: REST는 아키텍처 스타일의 일반적인 가이드라인이기 때문에 각 구현 사례가 다를 수 있습니다. 이로 인해 표준화 부재가 발생할 수 있습니다.
• 오버헤드: 일부 경우에는 RESTful API가 추가적인 HTTP 통신 오버헤드를 가질 수 있습니다. 특히, 작은 데이터 양을 요청하거나 응답하는 경우에도 오버헤드가 발생할 수 있습니다.
• 복잡한 요청의 처리: 복잡한 기능을 가진 요청이나 응답의 경우, URI 구조가 복잡해지고 API의 디자인이 복잡해질 수 있습니다.
• 보안 이슈: RESTful API는 간편한 접근을 허용하므로 보안적인 고려가 필요합니다. 인증과 권한 부여 메커니즘이 필요할 수 있습니다.
• 클라이언트와 서버 간의 밀접한 결합: 클라이언트와 서버 간의 통신은 URL과 HTTP 메소드에 의존하기 때문에, 서버의 변경이나 업데이트 시 클라이언트에 영향을 줄 수 있습니다.
• 무상태(Stateless) 특성: 일부 상황에서 클라이언트의 상태 정보를 유지하기 어려울 수 있습니다. 이로 인해 클라이언트와 서버 간의 추가적인 통신이 필요할 수 있습니다.