[SpringBoot] REST API (1)

[REST란?]

• REST는 인터넷과 같이 복잡한 네트워크 통신이 등장함에 따라, 이를 관리하기 위한 지침으로 만들어졌다.
• 대부분의 애플리케이션은 다양한 태스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신을 해야한다.
• 최근 서버 프로그램은 다양한 브라우저와 스마트폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야하기 때문에 이러한 멀티플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색할 결과, REST에 관심을 가지게 되었다.
• REST는 Representational State Transfer의 약어로써 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.
• HTTP URI를 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, DELETE, PATCH 등)를 통해 해당 자원에 대한 CRUD Operation을 적용한다.
• 간단하게 정의하자면 REST는 HTTP URI를 통해 클라이언트와 서버 사이의 통신하는 방식이다.

 

[REST의 특징]

1. Uniform Interface : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 의미한다.
2. Stateless (무상태성) : REST는 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다. 세션이나 쿠키를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리한다. 이 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순하다.
3. Cacheable (캐시 기능) : REST의 가장 큰 특징 중 하나는 HTTP라는 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하다.
4. Self-descriptiveness (자체 표현 구조) : REST는 REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 구성되어있다.
5. Client-Server 구조 : REST 서버는 API 제공, 클라이언트는사용자 인증이나 컨텍스트 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간의 의존성이 줄어들게 된다.
6. 계층형 구조 : REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이와 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

 

[REST의 장점]

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

 

[REST의 단점]

• 표준이 존재하지 않는다.
• 사용할 수 있는 메서드가 HTTP Method로 4가지만 가능하다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 더 어렵게 보인다.
• 구형 브라우저가 아직 제대로 지원을 못해주는 부분이 존재한다.

HTTP Method를 통한 REST 방식 (출처 : https://junvelee.tistory.com/107)

 

[REST API란?]

• REST API는 클라이언트와 서버 간의 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다.
• 여기서 말하는 API는 클라이언트와 웹 리소스 사이의 네트워크 통신을 위한 게이트웨이라고 생각하면 좋다. API는 다른 소프트웨어 시스템과 통신하기 위해 따라야하는 규칙을 정의한다.
• API는 항상 메뉴얼도 함께 제공이 되어야하고, URI를 모르면 클라이언트는 사용할 수 없다. 
• 최근 OpenAPI, 마이크로 서비스등을 제공하는 업체 대부분은 REST API를 제공한다.

 

[REST API 규칙]

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬래시 구분자(/)를 포함하지 않는다. REST API는 분명한 URI를 만들어 통신을 해야하기 때문에 혼동을 주지 않도록 경로 마지막에 슬래시를 사용하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는 데에 사용한다. 불가피하게 긴 URI 경로를 사용하게 될 때 하이픈을 사용하는 것이 좋다.
4. 언더바(_)는 URI에 사용하지 않는다.
5. URI 경로에는 영어 소문자가 적합하다. 대문자 사용은 피하도록 한다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.
6. REST API에서는 메시지 body 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.

 

[일반 사이트와 REST API 주소 체계 비교 예시]

1. 일반 사이트 주소 체계

게시물 목록 : GET http://localhost:8080/article/list
게시물 등록(폼) : GET http://localhost:8080/article/write
게시물 등록 : POST http://localhost:8080/article/write
게시물 단건 조회 : GET http://localhost:8080/article/1
게시물 수정(폼) : GET http://localhost:8080/article/1/modify
게시물 수정 : POST http://localhost:8080/article/1/modify
게시물 삭제 : GET http://localhost:8080/article/1/delete

 

2. REST API 주소 쳬계

게시물 목록 : GET http://localhost:8080/articles
게시물 등록 : POST http://localhost:8080/articles
게시물 단건 조회 : GET http://localhost:8080/articles/1
게시물 수정 : PATCH http://localhost:8080/articles/1
게시물 삭제 : DELETE http://localhost:8080/articles/1
회원 목록 : GET http://localhost:8080/members
회원 로그인 : POST http://localhost:8080/member/login
현재 로그인한 회원의 정보 : GET http://localhost:8080/member/me

REST API의 전체적 흐름 (출처 : https://junvelee.tistory.com/107)

 

[RESTful이란?]

• REST API를 제공하는 웹 서비스를 'RESTful 하다' 라고 표현한다.
• RESTful의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이다.
• RESTful한 API를 구현하는 근복적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 목적이라 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
• URI 규칙을 올바르게 지키지 않은 API와 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만, RESTful하지 못한 시스템이라고 일컫는다.