[Spring] REST, REST API
스프링 복습 및 정리 6P
REST란?
Representational State Transfer의 약자로, 웹 서비스와 네트워크 애플리케이션의 아키텍처 스타일을 정의한 것이다.
웹의 기본 원리를 따르면서 네트워크 기반의 소프트웨어 아키텍처를 설계하기 위한 원칙과 제약 조건을 제시한다.
REST란 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다.
REST란 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.
REST의 특징
자원 (Resource)
모든 것을 자원으로 표현한다.
예를 들어, 웹의 경우 HTML 문서, 이미지, 데이터베이스 레코드, 서비스 등을 모두 자원으로 간주한다.
고유한 식별자 (URI)
각 자원은 고유한 식별자인 URI(Uniform Resource Identifier)를 가진다.
URI를 통해 자원에 접근하고 조작한다.
인터넷 상에서 특정 자원을 고유하게 식별하는 문자열이다.
URI는 URL과 URN 두 가지 형태로 나뉜다.
URL(Uniform Resource Locator)- 자원을 나타내며, 웹 브라우저에서 주로 사용된다.
- 프로토콜(HTTP,FTP 등), 호스트(웹 서버의 주소), 포트(서비스의 포트 번호), 경로(웹 서버 내부의 경로), 쿼리 문자열 등으로 구성된다.
- 예) http://www.example.com:8080/products?category=electronics
URN(Uniform Resource Name)- 자원의 이름을 나타내며, 위치와는 독립적으로 자원을 식별한다.
- 주로 인터넷 상에서 지속성 있는 자원을 가리키는 데 사용된다.
- 예) urn:isbn:0451450523 (책의 ISBN 번호)
상태 없음 (Statelessness)
서버는 각 요청을 독립적으로 처리하며, 클라이언트의 상태를 관리하지 않는다.
모든 필요한 정보는 요청 자체에 포함되어야 한다.
자원의 표현 (Representation)
자원은 여러 형태의 표현을 가질 수 있다.
주로 JSON 또는 XML 형식으로 데이터를 표현하며, 클라이언트는 요청한 자원의 표현을 받는다.
유니폼 인터페이스 (Uniform Interface)
RESTful 시스템은 일관된 인터페이스를 제공하며,
HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 작업을 수행한다.
자기 서술적 메시지 (Self-descriptive Messages)
각 메시지는 자신이 어떻게 처리되어야 하는지에 대한 정보를 포함하며, 클라이언트는 이 정보를 통해 메시지를 이해한다.
계층화 (Layered System)
시스템은 계층화 구조로 설계되어 있어, 각 계층은 다른 계층의 내부 구현을 알 필요 없이 통신할 수 있다.
클라이언트-서버 구조 (Client-Server)
클라이언트와 서버는 독립적으로 발전할 수 있도록 분리되어 있다.
REST의 장점
간단하고 일관성 있는 인터페이스
HTTP메서드를 사용하여 자원에 대한 작업을 정의하므로, 인터페이스가 간단하고 일관성 있다.
자원 식별
모든 자원은 고유한 URI를 가지며, 이를 통해 자원을 식별할 수 있다.
무상태(Stateless)
REST 아키텍처는 요청 간에 상태 정보를 저장하지 않기 때문에 서버 부하가 낮다.
캐싱 지원
HTTP 프로토콜의 특징을 이용하여 응답을 캐싱할 수 있으므로, 성능을 향상시킬 수 있다.
다양한 데이터 포맷
XML, JSON, HTML 등 다양한 데이터 형식을 사용할 수 있어 데이터 교환에 용이하다.
REST의 단점
설계가 어려울 수 있음
RESTful API를 설계할 때 자원 식별과 URI 설계에 주의가 필요하며, 일관성 있는 설계를 유지하기 어려울 수 있다.
성능 제약
대용량 데이터 처리나 복잡한 연산에는 한계가 있을 수 있다..
보안
기본적으로 REST는 데이터 보안을 제공하지 않는다.
데이터 암오화 및 사용자 인증을 위한 추가 작업이 필요하다.
다양한 클라이언트 지원
모든 클라이언트가 REST를 지원하지 않을 수 있으며, 클라이언트와 서버 간의 버전 호환성을 유지하는 것이 어려울 수 있다.
REST API란?
REST를 기반으로 만들어진 API를 의미한다.
REST 아키텍처 스타일을 따르는 웹 서비스의 한 종류이다.
이 아키텍처 스타일은 네트워크 아키텍처 및 웹 서비스 디자인의 가이드라인을 제공하여
클라이언트와 서버간의 통신을 단순화하고 표준화 하는 데 중점을 둔다.
REST API의 설계
리소스 식별
먼저 제공할 리소스를 정의하고 URI로 식별한다.
예를 들어, 블로그 게시물을 제공하는 경으, 블로그 게시물은 리소스가 된다.
각 게시물은 고유한 ID를 갖고 URI로 식별된다.
HTTP 메서드 사용
각 리소스에 대한 작업을 HTTP 메서드를 사용하여 정의 한다.
GET : 리소스 조회
POST : 새 리소스 생성
PUT : 리소스 업데이트 또는 대체
DELETE : 리소스 삭제
URI 설계
URI는 명확하고 의미있게 설계되어야 한다.
아래에서 자세히 설명하겠다.
HTTP 응답 상태 코드
적절한 HTTP 응답 상태 코드를 사용하여 작업의 성공 또는 실패를 나타낸다.
예를 들어, 200은 성공, 201은 생성 성공, 404는 리소스 찾을 수 없음 등이다.
자세한건 참고 → https://preasim.github.io/26
요청 및 응답 형식
요청과 응답의 형식을 정의한다.
주로 JSON, XML을 사용하며, Content-Type과 Accept 헤더를 통해 형식을 지정한다.
REST API의 URI 설계
URI 설계 관례 중 일부 이다.
이 관계들은 가독성과 일관성을 높이기 위해 따르는 것이 좋지만 강제 규칙이 아니며, 특정 상황에 따라 예외를 허용할 수 있다.
URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
Bad Example http://posts/Test
Good Example http://posts/test
마지막에 슬래시 (/)를 포함하지 않는다.
Bad Example http://posts/test/
Good Example http://posts/test
언더바 대신 하이폰을 사용한다.
Bad Example http://posts/test_blog
Good Example http://posts/test-blog
파일확장자는 URI에 포함하지 않는다.
Bad Example http://posts/photo.jpg
Good Example http://posts/photo
행위를 포함하지 않는다.
Bad Example http://posts/delete-post/1
Good Example http://posts/post/1
Spring Boot 핵심 정리 모음
1P - POJO, IoC, DI, AOP, PSA >
3P - 컴포넌트 스캔과 의존성 자동 주입, @Autowired >
5P - Spring MVC / MVC의 동작 방식과 구성 요소 >
7P - HTTP Header, Rest Client >
9P - Service / Entity 클래스, Mapper / MapStruct >
10P - 예외 처리 (@ExceptionHandler, @RestControllerAdvice) >
11.1P - DDD, 도메인 엔티티 및 테이블 설계 >
11.2P - 데이터 액세스 계층 구현 (도메인 엔티티 클래스 정의) >
11.3P - 데이터 액세스 계층 구현 (서비스, 리포지토리 구현) >
12P - JPA(Java Persistence API) >
12.3P - Spring Data JPA 데이터 액세스 계층 구현 >
14P - Spring MVC Testing 단위 테스트 >
14.3P - 슬라이스 테스트 (API, 데이터 액세스 계층) >
14.5P - TDD (Test Driven Development) >
15P - API 문서화 (Documentation) >
댓글남기기