📍API란?
API(Application Programming Interface는 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어하고, 애플리케이션에서 사용할 수 있도록 만든 인터페이스를 의미한다. 즉, API는 컴퓨터나 소프트웨어를 서로 연결해 애플리케이션간 통신을 가능케 하는 역할을 수행한다
API 호출 과정의 빠른 이해를 위해 레스토랑의 주문을 예로 들어 보자!
손님은 테이블에서 주문을 하고, 웨이터가 주문을 주방에 전달한다. 주방에서는 주문에 맞추어 요리를 만들고, 웨이터를 통해 주문한 음식을 테이블에 서빙헤 주문을 수행한다.
즉, 손님은 클라이언트. 테이블은 UI, 웨이터는 API, 주방은 서버의 역할을 한다 볼 수 있다.
하지만 이 과정에서 손님은 어떻게 주문 처리가 이루어지는지 손님은 알지 못할 뿐더라 궁금해하지 않을 것이다. 이에 대한 주문 결과가 궁금할 뿐! 음식 재료가 없거나 주방 상황이 바빠 주문의 처리가 늦어지는 상황 등이 있을 수 있으나, 손님에게는 주문에 대한 응답만 해 주면 된다.
API에서 진행되는 작업을 클라이언트는 알지 못한다. 예를 들어 버튼을 클릭했을 때 이에 대한 결과가 궁금할 뿐 어떤 로직을 통해 데이터의 전달이 이루어지는지 전달할 필요가 없는 것과 같다. 따라서, 유저가 궁금해하는 결과를 전달하기 위해서는 API가 요청 받은 명령에 대한 결과를 정확히 전달해야 한다.
이러한 점을 보았을 때, API는 요청, 명령, 처리하는 역할을 수행을 통해 프로그램의 상호작용을 돕는 인터페이스임을 알 수 있다.
📍REST란?
💡우선... REST 에 대해 알아보자!
Rest는 HTTP URI를 통해 자원을 명시하고, HTTP Method인 POST, GET, PUT, DELETE에 해당 자원의 상태를 주고 받는 모든 것을 의미한다.
- 자원 (Resource) : URI
- 행위 (Verb) : HTTP 메소드 (POST, GET, PUT, DELETE)
- 표현 (Representation) : HTTP Message Pay Load (JSON, XML 등)
즉, REST는 HTTP URI를 통해 이미지, 텍스트, DB 등 모든 자원을 표현하고 HTTP 메서드를 통해 자원에 대한 CRUD 작업을 적용하는 것을 의미한다.
💡REST 의 특징은 뭐가 있을까
1. 클라이언트/서버 구조
REST는 명확한 서버-클라이언트 구조를 가지고 있고, 서버와 클라이언트는 각각 역할이 명확히 정의되어 독립적으로 작동한다.
클라이언트는 사용자 인증 밑 세션 관리의 역할을 수행하고, 서버는 API 제공과 비즈니스 로직 처리를 담당한다. 이와 같은 명확한 역할 분담으로 시스템이 모듈화되고 서로의 의존성을 낮추어 유연한 구조를 생성할 수 있다.
2. 무상태성
무상태성은 각 클라이언트 요청이 서버에 저장된 상태를 가지지 않고, 독립적으로 처리되는 특성을 나타낸다. 이는 클라이언트가 서버에 대한 이전 상태를 계속 유지할 필요가 없다는 원칙을 기반으로 한다.
3. 캐시 처리 기능
REST는 HTTP 프로토콜을 사용하므로 캐싱 기능을 적용할 수 있다.
캐시를 통해 한 번 받은 응답을 저장해 두었다가 동일한 요청 시에는 다시 서버에 요청하지 않고 캐시 된 응답을 사용함으로써 중복 요청에 대한 성능을 최적화하며, 네트워크 대역폭을 절약하고 응답 시간을 단축할 수 있다.
4. Self-descriptiveness 구조
RESTful API는 자체 표현 구조를 가지고 있어 요청 메시지만으로도 쉽게 이해할 수 있다. 이를 통해 명확한 메타데이터와 함께 클라이언트가 리소스를 효과적으로 활용할 수 있다.
서버는 클라이언트에게 리소스와 관련된 자세한 메타데이터를 제공한다. 이는 리소스의 구조, 속성, 허용된 작업 등을 명확하게 설명하며, 클라이언트는 서버의 응답을 받고 빠르게 이해할 수 있게 된다.
5. 계층화
RESTful 서비스는 계층 구조로 구성될 수 있다. 각 계층은 특정한 역할과 책임을 수행하며, 이는 단일 책임 원칙을 강조한다. 각 계층은 특정 부분에 집중하므로 전체 시스템을 모듈화 하여 유지보수를 쉽게 해 준다.
6. 유니폼 인터페이스
REST는 균일한 인터페이스를 제공하여 모든 웹 서비스가 공통의 디자인 원칙을 따를 수 있도록 한다. 이는 서버와 클라이언트 간의 통신을 단순하고 일관되게 만들어준다.
📍RESTful API와 REST API
REST API는 REST를 기반으로 서비스 API를 구현한 것이다. 이때 REST는 HTTP 기반으로 구현돼 HTTP를 지원하는 프로그램 언어이고 이를 통해 클라이언트, 서버를 구현할 수 있다.
이때, RESTful API 두 컴퓨터 시스템이 인터넷을 통해 정보를 보다 안전하고 쉽게 교환하기 위해 만들어 놓은 REST API를 제공하는 것을 의미한다.
API는 클라이언트와 서버 사이의 통신을 돕는 역할을 수행하고, REST API는 원활한 통신에 나아가 HTTP 규약에 따라 클라이언트-서버 간 정형화된 통신을 가능토록 한다. RESTful은 이런 점에서 API 통신의 호환성과 이해도를 높이는 것을 목표로 한다.
💡RESTful API의 설계 규칙
1. URI에 자원을 명시한다.
GET/~~~~
2. URI 구분자는 슬래시 '/'를 사용한다.
GET/diaries/~~~
3. URI의 마지막에 '/'를 포함하지 않는다.
GET/diaries/{id}
4. 하이픈 '-'를 사용한다.
GET/diaries/work-out
5. URI는 소문자로만 작성한다.
6. 확장자를 포함하지 않는다.
GET/diaries/work-out.json (x)
7. Query Parameter로 데이터를 검새한다.
GET/diaries?category=work-out
8. 리소스 간의 관계를 표현한다.
기본 관계 :GET/diaries/{id}/title
복잡한 관계 : GET/diaries/{id}/preferences/title
📍똑똑하게 협업하기!
💡Client가 좋아할 API path가 무엇일까?
- 어떤 자원을 제어할 것인지 식별 가능해야 함...
단수형/복수형에 대한 구분을 나타낼 것. Collection 자료일 경우 복수형으로 표현해 줘야 한다.
diaries를 기반으로 각각의 일기를 조회하는 경우diaries/{id}로 나타낼 수 있게!
- 명시적 행위. 자원을 어떻게 수행할 것인지 구체적으로 드러내기
(GET)의 경우,diaries/{id}/getTitle
💡Client가 좋아할 명세서는 무엇일까?
-
데이터 형식을 명확히 작성하기
당연한 말 같지만... 정말 중요하다. 알 수 없는 문제로400 에러가 떠 며칠간 고생했던 경험이 있는데, 알고 보니 서버와 클라이언트의 자료형 문제였다.annotation문제였다........ 그냥400 에러로만 나타나니400은 클라 잘못이라 생각하고 이것저것 고쳤는데 이런 부분도 신경 써서 작성하면 좋을 것 같다.
구현에 앞서 클라와 사전에 데이터 형식에 대해 얘기하는 시간을 가지면 좋을듯! -
유효하지 않은 부분에 에러 구문 처리해 주기
작은 부분이라 느껴질지라도 api 연결 시 훨씬 효율적으로 작업할 수 있게끔 도울 수 있는 부분!
참고
RESTful API란 무엇인가요?
Front End v. Back End Explained by Waiting Tables At A Restaurant
RESTful API 개발
