728x90
반응형
SMALL

REST API란 무엇인가요?

웹 기반 서비스에서 클라이언트와 서버 간의 통신을 쉽게하기 위해 사용되며, HTTP 프로토콜을 기반으로 자원(Resource)에 접근할 수 있는 인터페이스를 제공합니다.

 

프로젝트에 REST API를 사용한 이유가 무엇인가요? 

프로젝트에서 REST API를 사용하는 주요 이유는 다음과 같습니다.
1. 표준화된 인터페이스: REST API는 표준화된 인터페이스를 제공하므로, 개발자들이 쉽게 익힐 수 있고 다양한 플랫폼에서 사용할 수 있습니다.
2. 유지 보수성: REST API의 구성 요소들이 독립적으로 작동하므로, 한 쪽의 변경이 다른 쪽에 영향을 주지 않아 유지 보수가 쉽습니다.
3. 확장성: 클라이언트와 서버가 독립적으로 확장될 수 있어, 시스템의 확장성이 향상됩니다.
4. 간결성과 가독성: REST API는 자원에 대한 명확한 URI와 표준 HTTP 메서드를 사용하여 코드의 간결성과 가독성이 높습니다.

 

제 프로젝트에서 사용한 REST API는 아래와 같습니다.
  1. Ticket.java: 티켓 도메인 모델을 정의한 클래스입니다. 티켓과 관련된 속성과 메서드를 포함하고 있습니다.
  2. TicketRepository.java: 티켓 데이터에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하는 인터페이스입니다. 이를 통해 데이터베이스와의 상호 작용이 가능합니다.
  3. TicketService.java: 티켓과 관련된 비즈니스 로직을 처리하는 서비스 클래스입니다. TicketRepository를 사용하여 데이터베이스와 상호 작용하고, 티켓 생성, 조회, 수정, 삭제 등의 기능을 제공합니다.
  4. TicketController.java: 클라이언트의 요청을 처리하는 컨트롤러 클래스입니다. 이 클래스에서 REST API를 정의하며, HTTP 메서드와 URI를 사용하여 각 엔드포인트를 구성합니다.
  • 티켓 생성: POST /tickets
  • 티켓 조회 (전체): GET /tickets
  • 티켓 조회 (특정 ID): GET /tickets/{id}
  • 티켓 수정: PUT /tickets/{id}
  • 티켓 삭제: DELETE /tickets/{id}

REST API 특징

가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다는 것입니다.

 

REST API의 설계 규칙

1. URI는 명사를 사용(리소스명은 동사가 아닌 명사를 사용해야 합니다.)
         - 예) 다음과 같은 동사는 안됨!
               - /updateUser
              - /deleteUser
2.  슬래시( / )로 계층 관계를 표현합니다.
3. URI 마지막 문자로 슬래시 ( / )를 포함하지 않습니다.
4. 밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용합니다.
5. URI는 소문자로만 구성합니다.
6. HTTP 응답 상태 코드를 사용합니다.클라이언트는 해당 요청에 대한 실패, 처리 완료, 잘못된 요청 등에 대한 피드백을 받아야 합니다.
7. 파일확장자는 URI에 포함하지 않습니다. 

 

REST API와 RESTful API의 차이

RESTful API :
REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API 라고 합니다.
즉, REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭됩니다.

 

프로젝트에 REST API를 사용한 이유가 무엇인가요?

먼저, REST API를 사용하면 URI, HTTP Method를 통해 구현되어 있기 때문에 자원의 상태를 직관적으로 알 수 있습니다.
또한, 클라이언트와 서버를 명확하게 분리할 수 있기 때문에 적용하게 되었습니다.
각 엔드포인트는 클라이언트로부터 요청을 받아, TicketService를 통해 비즈니스 로직을 처리하고, 응답을 반환합니다. 이렇게 구성된 REST API를 통해 클라이언트는 티켓 관련 작업을 손쉽게 수행할 수 있습니다.

 

REST API 말고 다른 비교할만한 것을 알고 있나요?

GraphQL: 이 프로젝트에서는 GraphQL을 사용하여 티켓 관련 데이터를 처리할 수 있습니다. GraphQL을 사용하면 클라이언트가 필요한 데이터만 요청할 수 있으며, 여러 종류의 리소스를 한 번의 요청으로 가져올 수 있습니다. GraphQL을 적용하려면 기존의 REST 엔드포인트 대신 GraphQL 스키마와 리졸버를 정의해야 합니다.

gRPC: 이 프로젝트에서는 gRPC를 사용하여 티켓 관련 기능을 구현할 수 있습니다. gRPC는 낮은 지연 시간과 높은 처리량을 제공하며, 스트리밍 및 양방향 통신을 지원합니다. gRPC를 적용하려면 기존의 REST 엔드포인트 대신 Protocol Buffers를 사용하여 서비스와 메시지를 정의하고, 클라이언트와 서버 간의 통신을 구현해야 합니다.

REST API와는 다른 접근 방식을 제공하며, 이를 통해 프로젝트의 특성과 요구 사항에 따라 적합한 솔루션을 선택할 수 있습니다.

728x90
반응형
LIST

+ Recent posts