📒 API의 정의
Application Programming Interface 로 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜의 세트이다.
API 사용 시 장점 :: 데이터, 애플리케이션 및 기기를 연결하여 기술 전체가 서로 원활히 통신하고 잘 연동되도록 해준다.
구현 방식을 알지 못해도 제품 또는 서비스가 커뮤니케이션 할 수 있다.
API는 정보 제공자와 정보 사용자 사이에서 호출과 응답을 구성한다.
📒 REST (Restful)
Representational State Tranfer 의 줄임말
- HTTP URI를 통해 자원을 명시하고 Method를 통해 URI의 CRUD Operation을 적용하는 것을 의미
-> 어떤 자원에 대해서 CRUD 연산을 수행하기 위해 URI로 요청을 보내는 것
resource의 represetntation :: 문서, 그림, 데이터, 소프트웨어 자체에서 그 자원을 표현하는 이름
상태 전달 -> JSON 혹은 XML을 통해 데이터를 주고받음
HTTP URI(Uniform Resource Identifier) 를 통해 자원(Resource)을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
-
자원 기반 구조(Resource Orriented Architecture) , HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐이다.
-
웹 사이트의 이미지, 텍스트, DB 내용 등 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
🟠 REST 장점
HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
HTTP 프로토콜의 표준을 최대한 활용하여 여러추가적인 장점을 함께 가져갈 수 있게 해준다.
REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
서버와 클라이언트의 역할을 명확하게 분리한다.
🟠 REST 단점
표준이 존재하지 않는다.
사용할 수 있는 메소드가 4가지 밖에 없다 (HTTP Method 형태가 제한적이다.)
REST가 필요한 이유 :: 다양한 클라이언트의 등장으로 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 생각했을 때 REST가 효율적인 수단임
🟠 REST 구성 요소
- 자원(Resource) :: URI - 모든 자원에 고유한 ID가 존재하고 이 자원은 Server에 존재한다. 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상태에 대한 조작을 Server에 요청한다.
- 행위(Verb) :: HTTP Method - GET, POST, PUT, DELETE 와 같은 메서드를 제공
- 표현(Representation of Resource) :: 클라이언트의 요청에 따라 서버는 이에 적절한 응답을 보내는데 JSON, XML 등 여러 형태로 나타낼 수 있다.
🟠 REST 특징
- Server-Client 구조
- Stateless : HTTP 프로토콜은 Stateless Protocol 이므로 REST 역시 무상태성을 갖는다. Client의 context를 Server에 저장하지 않는다.
Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다. - Cacheable : Http의 특징인 캐싱 기능을 적용할 수 있다. 캐시 사용을 통해 응답 시간이 빨라진다.
- Layered System : Client는 REST API Server만 호출하고, REST Server는 다중 계층으로 구성될 수 있다.
- Uniform Interface : URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
- Self-descriptiveness : REST API 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.
📒 REST API
REST API는 REST 기반으로 서비스 API를 구현한 것이다.
API 가 RESTful 로 간주되려면 당연히 다음의 기준을 따라야한다.
- 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍쳐
- Stateless 클라이언트 - 서버 커뮤니케이션 :: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어있음
- Cacheable : 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
- 요청된 정보를 검색하는데 관련된 서버의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템
REST API는 따라야 할 기준이 있지만, 속도를 저하시키고 더 무겁게 만드는 XML 메세징, 빌트인 보안 및 트랜잭션 컴플라이언스 처럼 특정 요구 사항이 있는 SOAP 등의 규정된 프로토콜보다 사용하기 쉬운 것으로 간주된다.
🟠 REST의 규칙
- URI는 동사보다는 명사를 사용한다.
- 자원에 대한 행위는 HTTP Method로 표현한다.
GET /member/delete/1 (X)
DELETE /member/1 (O) - 슬래시로 계층 관계를 표현한다.
- URI 마지막에는 슬래시를 붙이지 않는다.
- URI는 소문자로만 구성한다.
- 가독성이 떨어지는 경우 하이픈을 사용한다. 밑줄(_) 사용하지않기
- 파일 확장자는 URI에 포함하지 않는다.
- RESTful API의 구성요소
- Resource : 서버는 Unique한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보낸다. 이 자원은 URI에 해당한다.
- Method :서버에 요청을 보내기 위한 방식
- Representation of Resource: 클라이언트와 서버가 데이터를 주고받는 형태로 json, xml, text 등이 있다.
참고 자료
https://www.redhat.com/ko/topics/api/what-is-a-rest-api
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://meetup.toast.com/posts/92
