728x90
REST(Representational State Transfer)란?
REST는 웹 애플리케이션을 설계하기 위한 아키텍처 스타일로, 자원의 표현(Representation)을 통해 상태를 전달(State Transfer)하는 것을 의미한다. RESTful 시스템은 이러한 아키텍처 스타일의 제약 조건을 모두 만족하는 시스템을 의미한다.
REST의 주요 제약 조건
- 클라이언트-서버 구조 : 클라이언트와 서버의 역할을 명확히 구분하여, 서로의 기능에 집중할 수 있도록 한다.
- 무상태성(Stateless) : 서버는 각 요청을 독립적으로 처리하며, 클라이언트의 상태를 서버에 저장하지 않는다. 모든 필요한 정보는 요청에 포함되어야 한다.
- 캐시 가능(Cacheable) : 서버의 응답은 명시적으로 캐시가 가능한지 여부를 나타내야 하며, 클라이언트는 이를 바탕으로 응답을 캐싱할 수 있다.
- 계층화된 시스템(Layered System): 클라이언트는 중간 계층을 통해서도 서버에 접근할 수 있으며, 중간 계층이 추가적인 기능(로드 밸런싱, 캐싱 등)을 수행할 수 있다.
- 인터페이스의 통합(Uniform Interface) : 일관된 인터페이스를 통해 시스템 구성 요소 간의 상호작용이 이루어지며, 이는 시스템의 단순성을 증가시킨다.
- 코드 온 디맨드(Code on Demand) (선택 사항) : 서버는 클라이언트에게 실행 가능한 코드를 전달하여 기능을 확장할 수 있다.
RESTful API 설계 시 중요한 요소
- URI(Uniform Resource Identifier) : 각 자원(Resource)은 고유한 URI로 식별된다.
- HTTP 메서드 : RESTful 서비스는 주로 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행한다.
- 상태 코드(Status Code) : HTTP 응답은 상태 코드를 포함하여 클라이언트에게 요청의 처리 결과를 알려준다.
- 헤더(Header)와 본문(Body) : 요청과 응답에는 메타데이터를 포함하는 헤더와 실제 데이터를 담는 본문이 포함된다.
RESTful 설계의 레벨(Levels)
RESTful 설계는 다양한 레벨로 구분되며, 각각의 레벨은 더 많은 제약 조건을 만족해야 한다:
- 레벨 0 : URI를 사용해 원격 프로시저 호출(RPC)을 수행하는 구조.
- 레벨 1 : 각 자원을 개별 URI로 식별하여 RESTful 설계를 시작.
- 레벨 2 : HTTP 메서드를 활용하여 RESTful 설계의 표준을 따름.
- 레벨 3 : HATEOAS(Hypermedia As The Engine Of Application State)를 도입하여 클라이언트가 서버로부터 받은 응답에 포함된 링크를 통해 다음 작업을 수행할 수 있도록 함.
HATEOAS의 역할
HATEOAS는 RESTful 시스템에서 중요한 개념으로, 클라이언트가 서버의 응답에 포함된 URI 링크를 통해 다음 요청을 동적으로 생성할 수 있도록 한다. 이를 통해 클라이언트는 서버의 URI 구조 변화에 구애받지 않고, 동적으로 URI를 사용할 수 있다.
RESTful의 장점과 고려사항
RESTful 아키텍처는 시스템의 유연성과 확장성을 높이고, 표준화된 프로토콜(HTTP)을 사용해 상호 운용성을 보장한다. 그러나 이를 제대로 구현하기 위해서는 각 제약 조건을 충실히 따라야 하며, 특히 HTTP 상태 코드와 메서드의 적절한 사용이 중요하다.
결론
REST는 웹 애플리케이션 설계를 위한 강력한 아키텍처 스타일로, 올바른 구현과 함께 시스템의 유지보수성과 확장성을 크게 향상시킬 수 있다. REST의 개념과 제약 조건을 이해하고 이를 기반으로 설계하는 것이 RESTful 서비스의 성공적인 구현의 핵심이다.
반응형
'Web' 카테고리의 다른 글
HTTP 요청-응답 흐름의 개요 (1) | 2024.09.12 |
---|---|
API vs Library vs Framework (0) | 2024.09.09 |
TCP와 UDP (0) | 2024.09.06 |
OAuth 2.0의 개념과 동작방식 (0) | 2024.09.04 |
인증(Authentication)과 인가(Authorization) (0) | 2024.09.03 |