RESTfulAPI

REST(REpresentational State Transfer) 원칙을 준수해 설계된 앱 프로그래밍 인터페이스(App Programming Interface)
REST는 클라이언트-서버 통신에서 리소스를 중심으로 한 설계 원칙을 기반으로 HTTP 프로토콜을 활용해 상태정보와 리소스를 교환함
RESTful : 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것 → 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높임

REST의 기본 원칙

1. 리소스 중심
   • API는 리소스를 기반으로 설계됨
   • 리소스는 URL로 표현되며 보통 명사를 사용함
     /user, /products, /orders

2. HTTP 메서드 활용
   • GET, POST, PUT, PATCH, DELETE

3. 무상태성(Statelessness)
   • 클라이언트와 서버 간의 요청은 독립적, 서버는 클라이언트의 이전 요청 상태 저장하지 않음

4. 계층적 시스템 (Layered System)
   • RESTful 시스템은 클라이언트와 서버 사이에 중간계층 둘 수 있음
     → 시스템의 확장성과 보안성을 높임

5. 캐시 가능
   • HTTP 헤더에 캐시 관련 정보를 포함하여 클라이언트가 응답 데이터를 캐시할 수 있도록 설계 가능
     → 서버 요청을 줄이고 성능을 최적화 가능

6. 인터페이스 일관성
   • 모든 리소스는 동일한 방식으로 표현되고, 클라이언트는 리소스에 접근하는 데에 표준화된 인터페이스를 사용함

장점

• 표준화된 설계 : HTTP 프로토콜을 기반으로 하기 때문에, 표준화된 설계로 이해와 구현이 용이함
• 확장성 : REST 계층적 설계와 무상태성 원칙은 확장성을 높이고, 다양한 클라이언트와 서버가 상호작용 할 수 있도록 함
• 성능 최적화 : 캐싱, 효율적인 데이터 구조를 통해 네트워크와 서버 부하를 줄임
• 플랫폼 독립성 : HTTP를 기반을 하므로 브라우저, 모바일 앱, IoT 등 다양한 플랫폼에서 사용 가능

단점

• 무상태성의 한계 : 클라이언트의 상태를 유지하지 않으므로, 요청마다 필요한 정보를 모두 보내야함 → 오버헤드 발생 가능
• 대규모 데이터 전송 비효율 : 복잡한 데이터 전송 비효율
• 실시간 데이터 처리의 부족 : REST는 양방향 통신에 적합하지 않음
• 엔드포인트 관리 : 리소스가 많을 수록 엔드포인트의 설계와 관리가 복잡해짐

주의사항

• 명확하고 일관된 URL
• 적절한 상태코드 반환
• 필요한 데이터만 반환
• 보안 강화 : AUthentication, Authorization 필수