REST(Representational State Transfer)는 웹 서비스를 위한 아키텍처 스타일 중 하나입니다. REST API는 HTTP 프로토콜을 기반으로 클라이언트와 서버 간의 통신을 위한 규칙과 규약을 제공합니다. REST API를 사용하면 애플리케이션 간의 데이터 전송이 가능해지며, 클라이언트가 서버의 리소스에 접근하고 조작할 수 있습니다. 이 포스팅에서는 REST API의 개념, 작동 원리, 주요 특징에 대해서 알아보겠습니다.
REST API는 클라이언트와 서버 간의 상호작용을 가능하게 하는 표준화된 방법을 제공합니다. 이를 통해 클라이언트는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 서버의 리소스에 접근하고 조작할 수 있습니다. 또한, 리소스를 중심으로 설계되어 각 리소스는 고유한 URI(Uniform Resource Identifier)를 가지며, 클라이언트는 URI를 통해 리소스에 접근합니다.
REST 구성
자원(Resource) - URI
행위 (Verb) - HTTP Method
표현 (Representations)
HTTP 메소드
- POST : 현재 리소스(Collection)보다 한 단계 아래의 리소스(Document) 생성
- GET : 현재 리소스(Collection, Document)를 조회
- PUT : 현재 리소스(Document)의 정보 수정 (해당 자원의 전체를 수정)
- DELETE : 현재 리소스(Document)를 삭제
- PATCH : 현재 리소스(Document)를 수정 (해당 자원의 일부를 수정)
적용 CRUD동작 예시
- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT)
- Delete : 데이터 삭제(DELETE)
- HEAD: 네트워크상 데이터의 header 정보 조회
작동 원리
클라이언트는 HTTP 메서드를 사용하여 요청을 보내고 -> 서버는 해당 요청을 처리하고 응답을 반환합니다
요청과 응답은 HTTP 프로토콜의 구조와 내용에 따라 전송됩니다. 통일된 인터페이스를 제공하여 클라이언트가 일관된 방식으로 리소스에 접근하고 조작할 수 있도록 합니다. 이를 위해 HTTP 메서드를 적절하게 사용하고, URI 구조를 설계하고, 상태 코드와 오류 처리를 제공합니다.
잘 설계된 RESTful한 API는 확장성과 유지보수성을 향상시키는데 큰 도움이 됩니다. 따라서 REST API의 개념과 원리를 이해하고 적절하게 활용하여 웹 서비스를 구현하는 것이 중요합니다.
설계 원칙
-
리소스 중심적 설계
REST API는 리소스를 중심으로 설계되어야 합니다. 각 리소스는 고유한 URI를 가지며, 클라이언트는 URI를 통해 리소스에 접근하고 조작합니다. 예를 들어 /users, /products, /orders와 같은 리소스에 대한 URI를 사용할 수 있습니다. -
명확하고 직관적인 URI
URI는 리소스를 나타내는 동시에 직관적이고 명확해야 합니다. 의미 있는 단어와 구조적인 패턴을 사용하여 URI를 설계하는 것이 좋습니다. 예를 들면, /users/{id}와 같은 URI는 특정 사용자의 정보를 나타내기에 적합합니다. -
적절한 HTTP 메서드 사용
HTTP 메서드를 적절하게 사용하여 리소스에 대한 작업을 정의해야 합니다. 가장 일반적으로 사용되는 메서드는 GET, POST, PUT, DELETE입니다. GET은 리소스를 조회할 때, POST는 리소스를 생성할 때, PUT은 리소스를 수정할 때, DELETE는 리소스를 삭제할 때 사용됩니다. -
상태 코드와 오류 처리
서버는 적절한 상태 코드를 반환하여 요청의 결과를 전달해야 합니다. HTTP 상태 코드는 요청이 성공했는지, 실패했는지, 어떤 종류의 오류가 발생했는지를 나타냅니다. 예를 들어, 200은 성공, 404는 리소스를 찾을 수 없음, 500은 서버 오류를 나타냅니다. 또한, 오류가 발생한 경우 적절한 오류 메시지를 포함하여 클라이언트에게 알려주어야 합니다. -
적절한 데이터 포맷 선택
REST API는 다양한 데이터 포맷을 지원할 수 있습니다. 가장 일반적으로 사용되는 데이터 포맷은 JSON과 XML입니다. 선택한 데이터 포맷은 클라이언트와 서버 간의 데이터 교환을 쉽게 할 수 있도록 해야 합니다. -
API 문서화
REST API는 명확하게 문서화되어야 합니다. API 사용 방법, 리소스 구조, 요청과 응답의 형식, 인증 방법 등을 상세히 설명하는 문서를 제공해야 합니다. 이를 통해 클라이언트 개발자가 API를 쉽게 이해하고 사용할 수 있습니다.
주요 특징
- 리소스 중심의 설계
REST API는 리소스(데이터, 서비스 등)를 중심으로 설계됩니다. 각 리소스는 고유한 URI를 가지며, 클라이언트는 URI를 통해 리소스에 접근하고 조작합니다. 이를 통해 API는 데이터를 관리하고 공유하는 데 중점을 둡니다.
- 무상태성(Stateless)
REST API는 클라이언트의 상태를 서버가 유지하지 않습니다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 클라이언트의 요청은 그 자체로 완전한 정보를 포함하며(쿠키,세션), 서버는 클라이언트의 요청에 대한 응답을 반환한 후 상태를 유지하지 않습니다. 이는 서버의 확장성을 높이고 클라이언트의 유연성을 제공합니다.
- 통일된 인터페이스
REST API는 통일된 인터페이스를 제공합니다. 이는 클라이언트가 서버와 상호작용하기 위해 일관된 방식을 사용할 수 있음을 의미합니다. HTTP 프로토콜을 기반으로 하며, 일반적인 HTTP 메서드(GET, POST, PUT, DELETE 등)와 URI를 사용하여 리소스에 접근하고 조작합니다.
- Self-descriptiveness (자체 표현 구조)
REST API는 자체 서술적인 특성을 가지고 있습니다. 이는 API 자체가 어떤 동작을 수행하는지 명확하게 설명할 수 있음을 의미합니다. 즉, REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다는 것입니다. 이는 API 문서화의 중요성을 강조하며, 개발자와 클라이언트 간의 의사소통을 원활하게 해줍니다.
- 캐싱(Caching)
REST API는 캐싱을 지원합니다. 서버가 리소스의 응답을 캐시하여 동일한 요청에 대해 중복 작업을 피할 수 있습니다. 이는 성능을 향상시키고 네트워크 트래픽을 줄일 수 있습니다.통합적으로, REST API의 주요 특징은 확장성, 유연성, 성능, 이해하기 쉬운 인터페이스 등을 제공하여 웹 서비스 개발에 효과적인 방법을 제공한다는 것 입니다.
그렇다면 RESTful한 API 구현은 어떻게 해야할까요? 사실 위에서 설명한 내용만 잘 지켜도 성공적이라고 볼 수 있겠습니다.
-
URI
URI는 리소스를 나타내는데 사용됩니다. 각 리소스에 대해 고유하고 직관적인 URI를 설계해야 합니다.
ex) /users: 사용자 리소스, /users/{id}: 특정 사용자의 정보 -
HTTP 메서드 활용
적절한 HTTP 메서드를 사용하여 리소스에 대한 작업을 정의해야 합니다. 일반적으로 사용되는 메서드는 GET(조회), POST(생성), PUT(수정), DELETE(삭제)입니다. -
상태 코드 활용
서버는 적절한 HTTP 상태 코드를 반환하여 요청의 결과를 전달해야 합니다. 상태 코드는 요청이 성공적인지, 실패한지, 어떤 종류의 오류가 발생했는지를 나타냅니다. -
적절한 데이터 포맷 선택
REST API는 다양한 데이터 포맷을 지원할 수 있습니다. 가장 일반적으로 사용되는 데이터 포맷은 JSON과 XML입니다. -
문서화
RESTful한 API는 명확하고 포괄적으로 문서화되어야 합니다.
다 위에서 다뤘던 내용이죠? RESTful한 API 구현 가이드라인은 웹 서비스 개발에 있어서 중요한 역할을 합니다. 이를 준수하면 확장 가능하고 유지보수가 용이한 API를 구현할 수 있으며, 클라이언트와 서버 간의 상호작용을 원활하게 할 수 있습니다.
