본문 바로가기

카테고리 없음

RESTful하게 API를 짜려면 어떻게 할까?

API(Application Programming Interface)란?
다른 소프트웨어 시스템과 통신하기 위해 따라야하는 규칙을 정의한다
웹 API : 클라이언트와 웹 리소스 사이의 게이트웨이

클라이언트
웹에서 정보에 액세스하려는 사용자이다
API를 사용하는 사람 또는 소프트웨어 시스템을 말한다

리소스
다양한 어플리케이션이 클라이언트에게 제공하는 정보이다
리소스는 이미지, 동영상, 택스트, 숫자 등 모든 유형의 데이터가 될 수 있다
서버는 클라이언트에 리소스를 제공하는 시스템이다
서버는 API를 사용하여 리소스를 공유, 보안, 제어 및 인증을 유지하면서 웹 서비스를 제공한다

REST(Repesentational State Transfer)
API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍쳐이다
자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것이다

 


REST 란?
1. HTTP URI(Uniform Resource Identifier)을 통해 자원을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH)를 통해
3. 해당 자원(URI)에 대한 CRUD Opertation을 적용하는 것이다

 


CRUD(Create, Read, Update, Delete) Operation이란?
CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능이다


REST 구성요소
1. 자원(Resource): HTTP URI
2. 자원에 대한 행위(Verb): HTTP Method
3. 자원에 대한 행위의 내용(Resperesntation): HTTP Message Pay Load

REST의 특징

1. Server-Client (서버-클라이언트 구조)
2. Stateless(무상태)
3. Cacheable(캐시 처리 가능)
4. Layered System(계층화)
5. Uniform Interface(인터페이스 일관성)

 


REST의 장단점

장점


1. 확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다
무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다
잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적 또는 완전히 제거한다
이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다

2. 유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다
각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다
서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다
애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다
예) 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다

3. 독립성
REST API는 사용되는 기술과 독립적이다
API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다
또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다

HTTP 프로토콜의 인프라를 그대로 사용하므로 RESP API 사용을 위한 별도의 인프라를 구축할 필요가 없다
HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다
Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다
여러가지 서버스 디자인에서 생길 수 있는 문제를 최소화한다
서버와 클라이언트의 역할을 명확하게 분리한다

단점
표준 자체가 존재하지 않아 정의가 필요하다
HTTP Method 형태가 제한적이다
브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보타 Header 정보의 값을 처리해야하므로 전문성이 요구된다

REST API는 REST 원리를 따르는 API 를 의미한다
 


REST API 규칙

1. URI 는 동사보다는 명사, 대문자보다는 소문자를 사용해야한다
나쁜예) http://api.com/Running/
좋은예) http://api.com/run

2. 마지막에 슬래시 (/)를 포함하지 않는다
나쁜예) http://api.com/test/
좋은예) http://api.com/test

3. 언더바 대신 하이픈을 사용한다
나쁜예) http://api.com/test_blog
좋은예) http://api.com/test-blog

4. 파일확장자는 URI에 포함하지 않는다
나쁜예) http://api.com/photo.jpg
좋은예) http://api.com/photo

5. 행위를 포함하지 않는다
나쁜예) http://api.com/delete-post/1
좋은예) http://api.com/post/1



RESTful
REST 원리(REST API 설계 규칙)를 따르는 시스템이다
모든 CRUD 기능을 POST 로 처리하는 것은 RESTful 하지 못한 예이다

RESTful API란,
두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다
안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원한다

RESTful API 클라이언트 요청에 포함되는 것은 아래와 같다

1. 고유 리소스 식별자
서버는 고유한 리소스 식별자로 각 리소스를 식별한다
일반적으로 URL(Uniform Resource Locator)를 사용하여 리소스 식별을 수행한다
URL은 리소스에 대한 경로를 지정한다
URL은 웹 페이지 방문하기 위해 브라우저에 입력하는 웹사이트 주소와 유사하다

이는 요청 엔드포인트라고도 한다
클라이언트가 요구하는 사항을 서버에 명확하게 지정한다

2. 메서드
HTTP(Hypertest Transfer Protocol)을 사용하여 RESTful API를 구현한다
HTTP 메서드는 리소스에 수행해야하는 작업을 서버에 알려준다

GET
클라이언트는 서버의 지정된 URL에 있는 리소스에 액세스한다
GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다

POST
클라이언트는 POST를 사용하여 서버에 데이터를 전송한다
요청과 함께 데이터 표현(expression)이 포함된다
동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러번 생성하는 부작용이 있다

PUT
클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트한다
POST와 달리 RESTful 웹 서비스에서 동일한 PUT 요청을 여러번 전송해도 결과는 동일하다

DELETE
클라이언트는 DELETE 요청을 사용하여 리소스를 제거한다
DELETE 요청은 서버 사태를 변경할 수 있다
사용자에게 적절한 인증이 없으면 요청이 실패한다

3. HTTP 헤더
요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터이다
예를 들어 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공한다

데이터
REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다

파라미터
RESTful API 요청에는 수행하야할 작업에 대한 자세한 정보를 서버에 제공한다

파라미터의 유형

  • URL 세부정보를 지정
  • 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터
  • 클라이언트를 빠르게 인증하는 쿠키 파라미터