RESTful API ( Representational State Transfer )란 ?
HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여
특정한 형태로 전달하는 방식
REST의 글자 의미에서 들어나듯이 REST의 뜻을 직역하면 '대표적인 상태 전송'이라는 뜻인데요, 대표적인 데이터 처리 기능에는 CRUD가 있죠?
한 마디로 CRUD 요청 전송이라고 표현할 수 있어요.
조금 더 구체적으로 풀어보면 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Resource)로 요청을 보내는 것으로 이를 보내는 방식(Method)으로 Get, Post 등을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현됩니다.
그리고 swagger나 talend api 와 같은 툴을 활용하여 RESTful API를 테스트하고, 문서화하거나 시각화할 수 있습니다.
REST API 방식의일례로 http://localhost:8080/user URI에 POST 방식을 활용하여 JSON의 형태로 데이터를 전달할 수 있습니다.
이를 앞서 언급한 정의에 따라 치환하여 표현할 경우 URI의 경우 Resource, POST 요청의 경우 Method, JSON의 경우 자원의 형태를 의미합니다. 이러한 규칙을 갖고 설계 API를 REST API 또는 Restful API라고 합니다. 그럼 이제 각 요소에 대해 자세히 살펴보겠습니다
Resource ⮕ 고유한 식별자를 갖는 URI (Uniform Resource Identifier) 형태로 표현되며, 클라이언트가 이러한 Resource로 request를 보내게 됩니다.
Method⮕ Server로 요청을 보내는 방식으로 GET,PUT,POST,DELETE,PATCH가 있습니다. CRUD 연산에 맞는 방식으로 서버에 요청해야만 연산이 행해질 수 있습니다.
Representation of Resource⮕ 클라이언트와 서버가 데이터를 주고 받는 형태로 json, xml, text, rss 등이 있습니다. Key와 Value 형식을 갖는 Json을 가장 많이 사용합니다.
RESTful API 주요 원칙
1. 무상태성 ( Statelessness )
⮕ 서버는 클라이언트의 상태를 저장하지 않습니다. 각각의 클라이언트의 요청을 별개의 것으로 인식하며, 각 요청은 필요한 모든 정보를 포함하여아합니다. Rest API는 세션정보나 쿠키정보를 활용하여 작업을 위한 상태정보를 저장 및 관리하지 않습니다. 이러한 무상태성으로 인해 서버에서 불필요한 정보를 관리하지 않으며 구현이 단순합니다. ( 서버에 부담이 적음 )
2. 클라이언트-서버 구조 ( Client-Server Architecture )
⮕ 클라이언트와 서버는 분리된 구조를 가집니다. 클라이언트는 사용자 인증, Context(세션, 로그인 정보) 등을 직접 관리하며 서버는 API를 제공함으로써 클라이언트와 서버간의 의존성을 줄입니다. ( 유지 보수가 용이하다 )
3. 계층화 시스템 ( Layered System )
⮕ 클라이언트는 중간 서버 ( 프록시, 게이트웨이 등)을 통해 서버와 통신 가능하며, 이를 통해 보안, 로드 밸런싱 등의 이점을 얻을 수 있습니다. 하지만 클라이언트는 서버와 직접 통신하는 지, 중간 서버와 통신하는 지 알 수 없습니다.
4. 캐시 가능성 ( Cacheable )
⮕ HTTP라는 기존 웹 표준을 사용하기 때문에 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원합니다. 서버는 클라이언트에 응답을 보낼 때 캐시의 상태를 포함하여 캐싱을 제어할 수 있습니다. 이는 대량의 요청을 효율적으로 처리하도록 도와줍니다.
5. 균일한 인터페이스 ( Uniform Interface )
⮕ 모든 API 요청은 일관된 방식( URI에 대한 요청과 Method를 사용한 작업수행 )으로 수행되며, 이는 Client의 플랫폼에 무관하여 특정 언어나 기술에 종속되지 않는 특징을 의미합니다. 즉 모든 플랫폼에서 요청 가능합니다.( Loosely Coupling 느슨함 결합 )
번외+ 온디맨드 코드 ( Code on Demand )
⮕ 서버가 클라이언트에게 실행 가능한 코드를 전달하여 클라이언트 측에서 특정 기능을 수행하도록 하는 개념으로 REST 아키텍처의 선택적 제약 조건 중 하나입니다. 최근엔 전송된 코드가 서버의 관리를 벗어난다는 문제로 인한 보안성 측면에서 잘 사용되지 않습니다
RESTful API의 단점
- 대용량 데이터 전송 비효율:
- 많은 양의 데이터를 주고받을 때, HTTP 기반 통신의 오버헤드가 발생할 수 있습니다.
- 대용량 데이터를 효율적으로 전송하기 위해 추가적인 최적화가 필요할 수 있습니다.
- 표준의 부재:
- REST 자체는 아키텍처 스타일이기 때문에, 구체적인 구현 방법에 대한 표준이 없습니다. (URI 설정 컨벤션은 존재)
- 이로 인해 API 설계 시 일관성을 유지하기 어렵고, 다른 RESTful API 간의 호환성이 떨어질 수 있습니다.
- 실시간 통신에 대한 제한:
- REST는 기본적으로 요청-응답 방식의 통신을 사용하므로, 실시간 양방향 통신(WebSocket 등)에는 적합하지 않습니다.
- 실시간 기능이 필요한 경우, 다른 기술과 함께 사용해야 할 수 있습니다.
출처
'Server' 카테고리의 다른 글
도커(Docker)에 대하여 (0) | 2024.06.22 |
---|---|
CI와 CD에 대하여 (Continuous Integration / Deployment ) (0) | 2024.06.14 |
JPA와 MyBatis (ORM, SQL Mapper)에 대하여 (0) | 2024.06.09 |
Stateful과 Stateless (0) | 2024.05.19 |
java.lang.IndexOutOfBoundsException (MyBatis) (0) | 2024.05.18 |
RESTful API ( Representational State Transfer )란 ?
HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여
특정한 형태로 전달하는 방식
REST의 글자 의미에서 들어나듯이 REST의 뜻을 직역하면 '대표적인 상태 전송'이라는 뜻인데요, 대표적인 데이터 처리 기능에는 CRUD가 있죠?
한 마디로 CRUD 요청 전송이라고 표현할 수 있어요.
조금 더 구체적으로 풀어보면 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Resource)로 요청을 보내는 것으로 이를 보내는 방식(Method)으로 Get, Post 등을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현됩니다.
그리고 swagger나 talend api 와 같은 툴을 활용하여 RESTful API를 테스트하고, 문서화하거나 시각화할 수 있습니다.
REST API 방식의일례로 http://localhost:8080/user URI에 POST 방식을 활용하여 JSON의 형태로 데이터를 전달할 수 있습니다.
이를 앞서 언급한 정의에 따라 치환하여 표현할 경우 URI의 경우 Resource, POST 요청의 경우 Method, JSON의 경우 자원의 형태를 의미합니다. 이러한 규칙을 갖고 설계 API를 REST API 또는 Restful API라고 합니다. 그럼 이제 각 요소에 대해 자세히 살펴보겠습니다
Resource ⮕ 고유한 식별자를 갖는 URI (Uniform Resource Identifier) 형태로 표현되며, 클라이언트가 이러한 Resource로 request를 보내게 됩니다.
Method⮕ Server로 요청을 보내는 방식으로 GET,PUT,POST,DELETE,PATCH가 있습니다. CRUD 연산에 맞는 방식으로 서버에 요청해야만 연산이 행해질 수 있습니다.
Representation of Resource⮕ 클라이언트와 서버가 데이터를 주고 받는 형태로 json, xml, text, rss 등이 있습니다. Key와 Value 형식을 갖는 Json을 가장 많이 사용합니다.
RESTful API 주요 원칙
1. 무상태성 ( Statelessness )
⮕ 서버는 클라이언트의 상태를 저장하지 않습니다. 각각의 클라이언트의 요청을 별개의 것으로 인식하며, 각 요청은 필요한 모든 정보를 포함하여아합니다. Rest API는 세션정보나 쿠키정보를 활용하여 작업을 위한 상태정보를 저장 및 관리하지 않습니다. 이러한 무상태성으로 인해 서버에서 불필요한 정보를 관리하지 않으며 구현이 단순합니다. ( 서버에 부담이 적음 )
2. 클라이언트-서버 구조 ( Client-Server Architecture )
⮕ 클라이언트와 서버는 분리된 구조를 가집니다. 클라이언트는 사용자 인증, Context(세션, 로그인 정보) 등을 직접 관리하며 서버는 API를 제공함으로써 클라이언트와 서버간의 의존성을 줄입니다. ( 유지 보수가 용이하다 )
3. 계층화 시스템 ( Layered System )
⮕ 클라이언트는 중간 서버 ( 프록시, 게이트웨이 등)을 통해 서버와 통신 가능하며, 이를 통해 보안, 로드 밸런싱 등의 이점을 얻을 수 있습니다. 하지만 클라이언트는 서버와 직접 통신하는 지, 중간 서버와 통신하는 지 알 수 없습니다.
4. 캐시 가능성 ( Cacheable )
⮕ HTTP라는 기존 웹 표준을 사용하기 때문에 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원합니다. 서버는 클라이언트에 응답을 보낼 때 캐시의 상태를 포함하여 캐싱을 제어할 수 있습니다. 이는 대량의 요청을 효율적으로 처리하도록 도와줍니다.
5. 균일한 인터페이스 ( Uniform Interface )
⮕ 모든 API 요청은 일관된 방식( URI에 대한 요청과 Method를 사용한 작업수행 )으로 수행되며, 이는 Client의 플랫폼에 무관하여 특정 언어나 기술에 종속되지 않는 특징을 의미합니다. 즉 모든 플랫폼에서 요청 가능합니다.( Loosely Coupling 느슨함 결합 )
번외+ 온디맨드 코드 ( Code on Demand )
⮕ 서버가 클라이언트에게 실행 가능한 코드를 전달하여 클라이언트 측에서 특정 기능을 수행하도록 하는 개념으로 REST 아키텍처의 선택적 제약 조건 중 하나입니다. 최근엔 전송된 코드가 서버의 관리를 벗어난다는 문제로 인한 보안성 측면에서 잘 사용되지 않습니다
RESTful API의 단점
- 대용량 데이터 전송 비효율:
- 많은 양의 데이터를 주고받을 때, HTTP 기반 통신의 오버헤드가 발생할 수 있습니다.
- 대용량 데이터를 효율적으로 전송하기 위해 추가적인 최적화가 필요할 수 있습니다.
- 표준의 부재:
- REST 자체는 아키텍처 스타일이기 때문에, 구체적인 구현 방법에 대한 표준이 없습니다. (URI 설정 컨벤션은 존재)
- 이로 인해 API 설계 시 일관성을 유지하기 어렵고, 다른 RESTful API 간의 호환성이 떨어질 수 있습니다.
- 실시간 통신에 대한 제한:
- REST는 기본적으로 요청-응답 방식의 통신을 사용하므로, 실시간 양방향 통신(WebSocket 등)에는 적합하지 않습니다.
- 실시간 기능이 필요한 경우, 다른 기술과 함께 사용해야 할 수 있습니다.
출처
'Server' 카테고리의 다른 글
도커(Docker)에 대하여 (0) | 2024.06.22 |
---|---|
CI와 CD에 대하여 (Continuous Integration / Deployment ) (0) | 2024.06.14 |
JPA와 MyBatis (ORM, SQL Mapper)에 대하여 (0) | 2024.06.09 |
Stateful과 Stateless (0) | 2024.05.19 |
java.lang.IndexOutOfBoundsException (MyBatis) (0) | 2024.05.18 |