동기식 요청/응답 통신 REST

 

REST

 > HTTP로 소통하는 프로세스 간 통신 규약

 > REST API는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식

 

REST API 예시

1. GET 메서드를 사용하여 사용자 정보를 조회하는 API

• URI: /users/{user_id}
• 요청 예시: GET /users/123
• 응답 예시:
• {
• "id": 123,
• "name": "John Doe",
• "age": 30,
• "email": "johndoe@example.com"
• }

 

1. POST 메소드를 사용하여 새로운 사용자를 생성하는 API

• URI: /users
• 요청 예시: POST /users
• {
• "name": "Jane Doe",
• "age": 25, "email":
• "janedoe@example.com"
• }
• 응답 예시:
• {
• "id": 124,
• "name": "Jane Doe",
• "age": 25,
• "email": "janedoe@example.com"
• }

 

1. PUT 메소드를 사용하여 사용자 정보를 수정하는 API

• URI: /users/{user_id}
• 요청 예시: PUT /users/123
• {
• "name": "John Smith",
• "age": 35,
• "email": "johnsmith@example.com"
• }
• 응답 예시:
• {
• "id": 123,
• "name": "John Smith",
• "age": 35,
• "email": "johnsmith@example.com"
• }

 

1. DELETE 메소드를 사용하여 사용자 정보를 삭제하는 API

• URI: /users/{user_id}
• 요청 예시: DELETE /users/123
• 응답 예시: HTTP 상태 코드 204(No Content)

 > HTTP 메시지의 body 부분을 JSON의 형태로 다루는 것이 보통이며, 이때 HTTP 헤더의 Content-Type의 값(MIME 타입)은 application/json으로 설정

 

REST의 장점

• 포스트맨, curl 등의 도구를 사용해 간편하게 테스트가 가능
• 요청/응답 통신을 직접 지원
• 시스템 아키텍처가 단순

 

REST의 단점

• 요청/응답만 지원
• 메시지를 주고받기 위해서는 클라이언트와 서버 프로세스가 둘 다 실행 중이어야만 함
• 요청 한 번으로 여러 리소스를 조회하기 어려움
• 메서드만으로는 한 번의 요청을 통해 이루어지는 다양한 작업들을 대표하기 어려움