1. REST API란?
REST(Representational State Transfer)의 약자로 '대표적인 상태 전달'이라는 의미를 가진다.
웹과 같은 분산 하이퍼미디어 시스템에서 사용하는 통신 네트워크 아키텍쳐와 비슷한데,
웹은 HTTP 프로토콜을 전송방식으로, URI를 식별 방식으로 사용하며 HTTP는 웹에서
GET, POST, PUT, DELETE 등 메소드를 이용해 정보를 주고받는 프로토콜이다
여기서 REST는 URI의 단순,간결한 장점을 계승한 네트워크 아키텍쳐라 보면 된다.
쉽게 요약해보자면 화면인 HTML을 리턴하는 방식이 아닌 사용자가 필요한 데이터 결과만 리턴해주는 방식이다.
URI ? URL?
URL : URI의 하위개념으로, 네트워크 상의 자원의 위치를 알려주기위한 규약으로 웹의 주소뿐만 아니라 컴퓨터 자원을 모두 나타낼 수 있고, 그 주소에 접속하기 위해선 URL에 맞는 프로토콜을 알아야 하며, 그와 동일한 프로토콜로 접속해야한다.
URI : 인터넷에 있는 자원을 나타내는 유일한 주소.
2. REST의 장점
- 구성요소간 상호작용의 규모 확장성
- 인터페이스 범용성
- 구성요소의 독립적인 배포
- 중간적 구성요소를 이용한 응답 지연감소 및 보안강화, 레거시 시스템 캡슐화
| 1. Uniform (유니폼 인터페이스) | URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일 |
| 2. Stateless (무상태성) | 작업의 상태 정보를 따로 저장하고 관리하지 않음. 그냥 서버를 통해 들어오는 요청만 처리하기에 자유도가 높고 불필요한 정보를 관리하지 않아 구현이 단순 |
| 3. Cacheable (캐시 가능) | HTTP 웹 표준을 그대로 사용, 따라서 HTTP가 가진 캐싱 기능 적용 가능 |
| 4. Self-descriptiveness (자체 표현 구조) | REST API 메세지만 보고도 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있음 |
| 5. Client-Server 구조 | 서버는 API, 클라이언트는 사용자 인증이나 컨텍스트 등을 관리하는 구조로 되어있어 역할이 구분되 서로 개발할 내용이 명확해지고 의존성이 줄어듬 |
| 6. 계층형 구조 | 다층으로 구성될 수 있으며 프록시나 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있음 |
3. REST의 구성
REST API를 개발할 때는 목적에 맞게 설계 후 진행하는 것이 좋으며, HTTP의 메소드, URI로 이뤄진 API서버이므로, 요청과 응답에 필요한 결과 모델을 구성해야 한다.
- 자원(resource) : URI
- 행위(action) : HTTP Method
- 표현(representations) : HTTP message Body
(자원에 대한 정리)
1. 동사 사용은 피하고 명사를 사용해야 한다.
2. 명사를 사용할 때는 단수보다는 복수를 사용하는게 좋은데, 보통 API를 설계할 때 DB에서 가져오는 자원이 여러개 이기 때문이다.
3. SQL의 질의문에 존재하는 키워드는 쿼리문과 혼동의 여지가 있어 사용을 피하는 것이 좋다.
4. 기존의 HTTP 메소드를 사용해 API를 구현하는 것이 좋다
| Resource | GET(read) | POST(create) | PUT(update) | DELETE(delete) |
| /items | 상품 목록 보기 | 상품 추가 | * | * |
| /items/{id} | 해당 ID값의 상품 보기 | * | 해당 ID값의 상품 수정 | 해당 ID값의 상품 삭제 |
POST -> POST를 통해 해당 URI를 요청하면 리소스를 생성한다.
GET -> GET을 통해 해당 리소스를 조회하며, 조회한 리소스에 대한 정보를 가지고 온다.
PUT -> PUT을 통해 해당 리소스를 수정한다
DELETE -> DELETE를 통해 리소스를 삭제한다
4. REST API 개발 및 사용
1. MVC 패턴을 이용한 방법
M(model)V(view)C(controller)로 이루어진 형태의 디자인 패턴으로 서버를 설계하며, Controller, Service(DAO), Repository로 나누어 데이터의 운반 처리를 세분화 하는 것이다. 기존 Spring MVC와의 차이점은 반환 형식의 차이가 존재하는데, 기존 spring mvc는 html이지만 rest api는 xml, json으로 반환한다.
2. Spring Boot data rest를 활용한 방법
다음으로 Spring Boot data rest는 Repository 하나만 있다면 DB에서 CRUD를 모두 수행할 수 있게 해주는 라이브러리로 MVC와 다르게 컨트롤러와 서비스가 존재하지 않고 repository 내부의 crud 메서드와 매핑해 처리 mvc는 직접 crud를 구현해야하지만 data rest는 그러지 않아도 된다.
5. URI 설계 시 주의사항
1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
ex) house/card
2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
ex) house/card (O)
house/card/ (X)
3. 불가피하게 긴 URI를 사용할 경우 하이픈(-)을 사용한다.
4. 밑줄(_)는 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. 파일의 확장자는 URI에 포함하지 않는다.
ex) house/card/joker.png (X)
- 리소스 간 관계 표현방법
ex) GET : users/{userid}/device
- 자원을 표현하는 Collection과 Document
Document는 단순히 문서로 이해해도 되며, 한 객체로 이해해도 된다.
Collection은 객체들의 집합이다.
위의 예시를 보면 card라는 컬렉션과 slot 이라는 다큐먼트로 표현되고 있는데,
card, players 컬렉션과 slot, 2를 의미하는 다큐먼트로 URI가 이루어진다.
여기서 중요한 점은 컬렉션은 복수로 사용하고 있다는 점이다.
6. HTTP 응답 상태 코드
직접 REST API를 설계후 CRUD를 이용할 때 다양한 HTTP 오류(상태코드)를 접할 수 있는데, 상태코드를 통해 어떤 부분이 문제가 생겼는지 확인할 수 있으니 잘 확인하는 것이 좋다.
| 상태 코드 | 내용 |
| 200 | 클라이언트의 요청을 정상적으로 수행했을 때 |
| 201 | 클라이언트가 POST를 통해 리소스 생성 작업 시에 리소스가 성공적으로 생성됬을 때 |
| 400 | 클라이언트의 요청이 부적합할 때 |
| 401 | 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청할 때 |
| 403 | 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 |
| 405 | 클라이언트가 요청한 리소스에서는 사용이 불가능한 메서드를 사용했을 때 |
| 301 | 클라이언트가 요청한 리소스에 대한 URI가 변경되었을 때 |
| 500 | 서버에 문제가 있을 때 |
(참고)
https://meetup.toast.com/posts/92
REST API 제대로 알고 사용하기 : NHN Cloud Meetup
REST API 제대로 알고 사용하기
meetup.toast.com
2022.12.08 추가 (RESTful api)
RESTful API
앞서 설명한 REST API를 제공하는 서비스를 RESTful 하다고 볼 수 있다.
이러한 restful api에도 개발 원칙이 있다.
- 행위는 명시적이어야 한다.
- 자기 서술적이어야 한다.
- 자원을 식별할 수 있어야 한다.
- HATEOS(Hypermedia as the Engine of Application State)
1. 행위는 명시적이어야 한다.
이 말은 그 행위를 위해 어떠한 방식이 강제적이지는 않지만, 예시로 Delete나 Update를 Get으로 해결해도 가능하지만 REST 아키텍쳐에 부합하지 않아서 REST라고 할 수 없다.
2. 자기 서술적이어야 한다.
데이터에 대한 메타 정보만 가지고 어떤 종류의 데이터인지, 어떤 애플리케이션을 실행해야하는지를 알 수 있어야 하는데, 데이터 처리를 위한 정보를 얻기 위해서 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다.
3. 자원을 식별할 수 있어야 한다.
제공하는 정보 데이터인 JSON이나 XML 등 URL 만으로 제어하고자 하는 자원을 알 수 있어야 하며, 자원을 제어하기 위해서, 자원의 위치, 종류등 알 수 있어야 한다
4. HATEOS(Hypermedia as the Engine of Application State)
클라이언트의 요청에 응답할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 하는데, 서로 다른 컴포넌트들을 유연하게 연결하기 위한 방법이 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼링크를 제공하는데, 이 링크를 통해 전체 네트워크와 연결된다.
REST의 단점
1. CRUD 메소드만 제공해서, 혹시나 다른 것을 처리할 시 해매할 수 있다.
2. HTTP에 많이 의존적이다.
3. REST는 URI, HTTP를 이용한 아키텍쳐의 방법에 중점을 두고 있아, 보안, 통신 규약 정책 등을 다루지 않아서 개발자가 이 부분에 대해서 설계와 구현을 진행해야 한다.
4. REST는 점대점(Point to Point)을 기본으로 하고 있어, 서버와 클라이언트가 연결을 맺고 상호작용 해야하는 어플리케이션의 개발에 적당하지 않다.
(참고)
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80#rest-api
'스프링 > 백엔드' 카테고리의 다른 글
| Repository와 Service (0) | 2022.06.12 |
|---|---|
| 로깅 간단히 알아보기 (0) | 2022.05.18 |
| InteliJ-Spring boot-dependencies (0) | 2022.03.09 |
| 스프링 부트의 테스트 코드(부제 : JUnit), 책: 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 (0) | 2022.02.10 |
| Compile과 implementation의 차이점 (0) | 2022.01.30 |