REST 라는 단어는 RE Presentational State Transfer 의 약자로 간단히 말해서 API를 생성하기 위한 패턴입니다
. API는 애플리케이션 프로그래밍 인터페이스 를 의미 합니다 .
REST API의 용도
REST API를 사용하면 애플리케이션이 서로 상호 작용하고 데이터를 교환할 수 있습니다. 예를 들어 모바일 애플리케이션이나 웹 애플리케이션을 구축한다고 가정해 보겠습니다. 해당 응용 프로그램에서 온도, 습도, 풍속 등과 같은 날씨 데이터를 표시하려고 합니다.
문제는 우리 애플리케이션에 이 날씨 데이터가 없다는 것입니다. 타사 REST API 서비스에서 정보를 제공합니다. 귀하의 애플리케이션은 날씨 데이터를 원하는 도시 이름을 보냅니다. 타사 REST API는 온도, 습도, 풍속 등과 같은 날씨 데이터를 애플리케이션으로 다시 보냅니다.
다른 REST API 예제
직원 포털을 구축한다고 가정해 보겠습니다. 직원 데이터는 REST API를 통해 애플리케이션에 제공됩니다. 따라서 여기서 직원 포털은 클라이언트이고 직원 데이터를 제공하는 REST API는 서버입니다. 클라이언트와 서버 간의 통신은 HTTP를 통해 이루어집니다. 더 안전한 옵션을 원하면 HTTPS를 사용할 수도 있습니다.
이 예에서 클라이언트는 웹 애플리케이션입니다. REST는 개방형 표준을 기반으로 하기 때문에 REST API는 다음과 같은 광범위한 클라이언트에서 사용할 수 있습니다.
- Web Browsers
- Mobile applications
- Desktop applications
- IOTs i.e Internet Of Things.
REST 제약
REST API를 구축할 때 일련의 규칙을 따라야 합니다. 이를 일반적으로 REST 제약 조건이라고 합니다. 다음은 일반적인 REST 제약 조건 중 일부입니다.
Client Server 제약
클라이언트는 요청을 보내고 서버는 응답을 보냅니다. 우리의 경우 클라이언트는 직원 데이터에 대한 요청을 보내는 직원 포털이고 서버인 REST API는 직원 데이터로 응답합니다. 이러한 분리는 클라이언트측 로직과 서버측 로직의 독립성을 보장합니다.
Stateless 제약
클라이언트와 서버 간의 통신은 요청 간에 상태 비저장이어야 합니다. 이것은 우리가 클라이언트와 관련된 서버에 아무것도 저장해서는 안된다는 것을 의미합니다. 클라이언트의 요청에는 서버가 해당 요청을 처리하는 데 필요한 모든 정보가 포함되어야 합니다. 이렇게 하면 서버에서 각 요청을 독립적으로 처리할 수 있습니다.
Cacheable 제약
제품 목록이나 회사의 부서 목록과 같이 서버에서 제공하는 일부 데이터는 자주 변경되지 않습니다. 이 제약 조건은 클라이언트가 이 데이터의 유효 기간을 알려주므로 클라이언트가 해당 데이터를 위해 계속해서 서버로 돌아올 필요가 없도록 합니다.
통일된 인터페이스
이름에서 알 수 있듯이 이 제약 조건은 클라이언트와 서버 간의 인터페이스를 정의합니다. 이 제약 조건은 REST API가 실제로 어떻게 작동하는지 이해하는 데 도움이 됩니다.
REST API 컨텍스트에서 리소스는 제품, 직원, 고객, 주문 등과 같은 데이터 엔터티입니다. 예를 들어 직원 데이터를 제공하는 REST API는 다음 URI(Uniform Resource Identifier)에서 직원 목록을 사용할 수 있도록 합니다.
- 여기서 사용하는 프로토콜은 http입니다. 또한 HTTPS를 사용하여 좀 더 안전하게 할 수 있습니다.
- pragimtech.com은 도메인입니다.
- URI의 /api 경로는 이것이 API임을 나타냅니다. 이것은 대부분의 사람들이 따르는 관습일 뿐입니다. 이 규칙을 사용하면 URL만 보면 이것이 REST API URL이라고 말할 수 있습니다.
- 마지막으로 /employees는 리소스 즉, 이 경우 직원 목록이 있는 끝점입니다.
제품과 같은 다른 리소스가 있는 경우. 그런 다음 제품 목록은 다음 끝점에서 사용할 수 있습니다.
따라서 각 리소스는 특정 URI로 식별됩니다. 예를 들어 직원 목록은 URI http://pragimtech.com/api/employees 에서 사용할 수 있습니다 . 마찬가지로 제품 목록은 URI http://pragimtech.com/api/products 에서 확인할 수 있습니다 .
URI와 함께 서버에 HTTP 동사를 보내야 합니다. 다음은 일반적인 HTTP verbs입니다.
- GET
- POST
- PUT
- PATCH
- DELETE
리소스로 수행할 작업을 API에 알리는 것은 이 HTTP 동사입니다. 다음은 모든 리소스에서 수행하는 4가지 일반적인 작업입니다. 예를 들어 새 직원을 만듭니다. 기존 직원을 편집, 업데이트 또는 삭제합니다.
따라서 각 요청과 함께 전송되는 URI와 HTTP 동사의 조합은 서버(예: REST API)에 리소스로 수행할 작업을 알려줍니다. 예를 들어,REST API는 Stateless 제약 조건을 준수해야 합니다. 이 제약 조건에 따라 클라이언트와 서버 간의 통신은 상태 비저장이어야 합니다. 즉, 클라이언트의 요청에는 서버가 해당 요청을 처리하는 데 필요한 모든 정보가 포함되어야 합니다.
신입 사원을 만들 때 요청
- Contains the URI …/api/employees
- The HTTP Verb – POST
- The employee object itself in the body of the request
기존 직원을 업데이트하는 요청
- Contains the URI …/api/employees/1. The id of the employee whose data we want to update is 1.
- The HTTP Verb – PUT
- The employee object that contains the changes is sent in the body of the request
PUT 과 PATCH 비교
PUT은 직원의 전체 개체 즉, FirstName, LastName, DOB, Gender, Email 등을 업데이트합니다. 기본적으로 개체의 모든 속성이 업데이트됩니다.
PATCH는 부분 업데이트, 즉 속성의 하위 집합만 수행하려는 경우에 사용됩니다. 직원 개체의 이름과 성별만 있을 수 있습니다.