공부/springboot
[REST] REST API
ㄱ ㅣ린
2023. 3. 4. 23:44
※ REST ( REpresentational State Transfer )
- 네트워크상에서 Client와 Server 사이의 통신 방식
- 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하는 아키텍처 스타일
- 자원을 이름으로 구분하여 해당 자원 상태(정보)를 주고받는 것
- HTTP URI( Uniform Resource Identifier )을 통해 자원을 명시, HTTP Method( Post, Get, Put, Delete )를 통해 해당 자원에 대한 CRUD( Create, Read, Update, Delete )를 적용하는 것
- 장점
- HTTP 프로토콜의 인프라를 사용하기 때문에 REST API 사용을 위해 별도의 인프라를 구축할 필요없다.
- Rest API 메시지가 의도하는 바를 쉽게 파악할 수 있다
- 서버와 클라이언트의 역할을 명확하게 분리한다.
- 즉, 자원 기반의 구조 설계의 중심에 자원이 있고, HTTP Method를 통해 자원을 처리하도록 설계된 아키텍처
- REST API 예시) https://dummy.restapiexample.com/api/v1/employees
| 서버 Server | 서비스 공급자 클라이언트에게 서비스를 제공 |
| 클라이언트 Client | 서비스 소비자. 브라우저나 다른 시스템 |
| 자원 Resource | 모든 정보(이미지, 글, 비디오 등) |
| Representation | 리소스를 표현하는 구체적인 방법. 예를 들면 JSON, XML, HTML 등을 사용해 리소스를 나타낼 수 있다. |
※ HTTP Method / CRUD Operation
| HTTP Method | CRUD Operation | ||
| POST | 생성 | CREATE | 생성 |
| GET | 읽기 | READ | 읽기 |
| PUT | 업데이트 | UPDATE | 업데이트 |
| DELETE | 삭제 | DELETE | 삭제 |
※ REST 특징
| 클라이언트 - 서버 ( Client - Server ) |
- 서버와 클라이언트는 서로 독립적이여야 한다. - 클라이언트가 알아야하는 정보는 요청된 리소스의 URI이며, 다른 방법으로 서버 애플리케이션과 상호작용할 수 없다. - 서버는 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트를 수정해서는 안된다 - 의존성이 줄어든다. 자원을 요청하는 클라이언트, 자원을 제공하는 서버 - Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다. - REST 서버: API를 제공하고 비즈니스 로직 처리 및 저장을 책임 |
| 무상태 ( Stateless ) |
- 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야한다. - 서버측 세션을 필요로 하지 않고, 서버는 클라이언트 요청과 관련된 데이터를 저장할 수 없다. - HTTP Protocol은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다. - 클라이언트의 context를 서버에 저장하지 않는다. 세션&쿠키 같은 context 정보를 신경쓰지 않아 구현이 단순 - 서버는 각각의 요청을 별개의 것으로 인식하고 처리한다. - 각 API 서버는 클라이언트의 요청만 단순 처리한다 |
| 인터페이스 일관성 ( Uniform Interface) |
- 요청이 어디에서 오든지 동일 리소스에 대한 API요청은 동일하게 보여야한다 - HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, 특정 언어난 기술에 종속되지 않는다. |
| 캐시 기능 ( Cacheable ) |
- HTTP가 가진 캐싱 기능을 적용할 수 있다 (대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다) - 캐시 사용을 통해 응답시간이 빨라지고 REST 서버 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다. |
| 레이어 시스템 ( Layered System ) |
- REST API는 호출과 응답이 서로 다른 계층을 통과하기 때문에, 중개자와 통신여부를 클라이언트나 서버가 알 수 없도록 설계되어야한다. - 클라이언트는 서버와 직접적으로 연결되면 안된다. - REST 서버는 다중 계층으로 구성될 수 있다. - API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다. - Proxy, 게이트웨어 같은 네트워크 기반의 중간 매체를 사용할 수 있다. |
| Code On Demand | - Server로부터 스크립트를 받아서 Client에서 실행한다 ( 반드시 충족안해도 됨 ) |
※ REST 구성요소
- 자원(Resource): URL
- 모든 자원에 고유 ID가 존재하고, Server에 존재한다.
- 클라이언트는 URL을 이용해서 자원을 지정하고, 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
- 행위(Verb): HTTP Method
- HTTP 프로토콜의 Method 사용. POST, GET, PUT, DELETE 같은 메서드 제공
- 표현(Representation of Resource)
- client가 자원의 상태(정보)에 대한 조작을 요청하면 server는 이에 응답을 보낸다.
- 하나의 자원은 JSON, XML 등의 형태의 Representation으로 나타날 수 있고, JSON이나 XML를 통해 데이터를 주고받는다.
※ REST API
- REST 기반으로 서비스 API를 구현하는 것을 REST API라고 한다.
- API(Application Programming Interface)
- 클라이언트가 리소스를 요청할 수 있도록 서버측에서 제공된 인터페이스
- API로 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능하도록 한다.
- API와 함께 항상 메뉴얼도 제공되어야한다. URI를 모르면 클라이언트는 사용할 수 없다.
- API(Application Programming Interface)
- 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어(델파이 클라이언트 뿐 아니라, 자바 C#, 웹 등)로 클라이언트, 서버를 구현할 수 있다.
※ REST API 설계 기본 규칙
- 참고: 리소스 원형
- 도큐먼트: 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
- 컬렉션: 서버에서 관리하는 디렉터리라는 리소스
- 스토어: 클라이언트에서 관리하는 리소스 저장소
- " / "는 계층관게를 나타내는데 사용한다
- URL 마지막 문자로 " / "를 포함하지 않는다
- URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며, URL이 다르면 리소스가 다르다는 뜻이다. 따라서 리소스가 다르면 URL도 달라져야한다
- 하이픈 " - " 은 가독성을 높이는데 사용한다 (긴 URL 경로를 사용할 시 + 밑줄 "_" 은 사용하지 않는다)
- URI 경로에는 소문자를 사용한다 (대문자 사용 지양)
- 파일확장자는 URI에 쓰지않는다
- 1. URL은 정보를 자원으로 표현해야한다.
- 1-1. resource는 동사보다 명사, 대문자보다는 소문자를 사용한다.
- 1-2. resource의 도큐먼트 이름으로는 단수 명사를 사용해야한다.
- 1-3. resource의 컬렉션 이름으로는 복수 명사를 사용해야한다
- 1-4. resource의 스토어 이름으로는 복수 명사를 사용해야한다.
- ex) GET /members/1
- 2. 자원에 대한 행위는 HTTP Method(POST, GET, PUT, DELETE )로 표현한다.
- 2-1. URL에 HTTP Method가 들어가면 안된다. ex) GET /members/delete/1 -> DELETE /members/1
- 2-2. URL에 행위에 대한 동사 표현이 들어가면 안된다. (CRUD 기능을 나타내는 것은 URL에 사용하지 않는다)
- 2-3. 경로 부분 중 변화하는 부분은 유일한 값으로 대체한다. (즉, id는 하나의 특정 resource를 나타내는 고유값)
- ex) student를 생성하는 루트: POST /students id가 12인 student를 삭제하는 루트: DELETE /students/12
※ REST API 설계 예시
| CRUD | HTTP verbs | Route |
| resource 생성 | POST | /resource |
| resource 목록 표시 | GET | /resource |
| resource 하나 내용 표시 | GET | /resource/:id |
| resource 수정 | PUT | /resource/:id |
| resource 삭제 | DELETE | /resource/:id |
| 응답 상태 코드 | |
| 100번대 | 전송 프로토콜 수준의 정보 교환 |
| 200번대 | 클라이언트 요청이 성공적으로 수행됨 |
| 300번대 | 클라이언트 요청을 완료하기 위해 추가적인 행동이 필요 |
| 400번대 | 클라이언트의 잘못된 요청 |
| 500번대 | 서버 오류 |
References
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html