[네트워크] Rest API란?

Rest API 란?

REST 기반으로 서비스 API를 구현한 것

 

 

그렇다면, Rest란?

REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

 

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

 

CRUD Operation이란?

 

CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다.

- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT, PATCH)
- Delete : 데이터 삭제(DELETE)

 

 

REST의 구성요소 3가지

1. 자원(resource) - URI
2. 행위(verb) - HTTP Method
3. 표현(Representations) : HTTP Message Pay Load  

 

URI(Uniform Resource Identifier) vs URL(Uniform Resource Locator)

1. // 추가예정

Rest API 공부를 하다가 URI에 대한 내용이 나와서, URI와 URL의 차이에 대해 정리하고 넘어가려 한다.

결론은, URI는 URL의 의미를 품고있다.

 

* 인터넷 환경에서 자원을 식별하기 위해 사용하는 방법

1) Path Variable 방식

/user/1

/user/2

 

2) Query Parameter 방식

/user?job=student

/user?job=student&age=10

 

 

URI = 위치/100 = URL/100

URL = 자원의 실제 위치

 

ex)

http://naver.com/index : 자원의 실제 경로이므로 URL이자 URI이다.

http://naver.com/user/100 : naver.com에서 100의 ID값을 가지고 있는 자원을 식별하는 경우이다.

~/user/ 까지 자원의 실제 위치이므로 URI임과 동시에 URL이며 끝의 /100은 식별자이므로 URL(http://naver.com/user/)을 포함한 URI이다.

 

http://naver.com/user?id=100 : ~/user까지는 자원의 실제위치이므로 URL, 뒤의 쿼리스트링 식별자(?id=100)포함한 전체 경로는 URI이다.

 

 

REST의 특징

1. Server-Client(서버-클라이언트 구조): 클라이언트 애플리케이션과 서버는 반드시 서로간 의존성 없이 개발되어야 한다.
2. Stateless(무상태): 요청들은 각각 독립적으로 처리되어야 한다.
3. Cacheable(캐시 처리 가능): 요청을 통해 보내는 자료들은 캐싱이 가능해야 한다.
4. Layered System(계층화): 요청을 처리하는 곳, DB에 저장하는곳 등 이런 여러가지 단계를 거쳐 요청을 처리해도 된다(여러개의 레이어를 거쳐 요청을 처리하게 만드는 것)
5. Uniform Interface(인터페이스 일관성): 하나의 URL로는 한 개의 데이터만 가져와야 한다.

 

REST의 장단점

장점

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

단점

• 표준이 자체가 존재하지 않아 정의가 필요하다.
• 사용할 수 있는 메소드가 한정적이다. = HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)
• 분산환경에는 부적합하다.

 

REST API 설계 규칙

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

 

2. 마지막에 슬래시 (/)를 포함하지 않는다.

http://naver.com/test/ (x) http://naver.com/test(o)

 

3. 언더바 대신 하이폰을 사용한다.

http://naver.com/test_blog (x) http://naver.com/test-blog (0)

 

4. 파일확장자는 URI에 포함하지 않는다.

http://naver.com/test/photo.jpg (x) http://naver.com/test/photo (o)

 

5. 행위를 포함하지 않는다.

http://naver.com/test/delete-photo/1  (x) http://naver.com/test/photo/1(o)

 

RESTful API란?

 

 = REST 아키텍처 스타일에 부합하는 API

• Restful API(Rest + ~ful): RESTful한 API
• RESTful하다: rest의 기본원칙을 성실히 지킨 서비스 디자인을 말한다.
• 꼭 http를 써야하는 건 아니다? -> 추가예정

 

RESTful 하게 API를 디자인한다는 것은 무엇을 의미하는가? (4가지)

1. 리소스와 행위를 “명시적”이고 “직관적”으로 분리한다.

• 리소스는 URL로 표현되는데, 리소스가 가리키는 것은 명사로 표현되어야 한다.
• 행위는 HTTP Method로 표현하고, CURD를 분명한 목적으로 사용한다.

 

2. Messagesms Header와 Body를 명확하게 분리해서 사용한다.

 

• Header: API 버전정보(애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤정보), 응답받고자 하는 MIME(마임) 타입 등을 담는다.
• Body: Entity에 대한 내용을 담는다.
• header와 body는 http header와 http body로 나눌 수 있고, http body에 들어가는 json 구조로 분리할 수도 있다.

3. API 버전을 관리한다.

 

• 환경은 항상 변하기 때문에 API의 signature가 변경될 수도 있음에 유의해야 한다.
• 특정 API를 변경할 때는 반드시 하위호환성을 보장해야 한다.

4. 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.

• 브라우저는 form-data형식의 submit으로 보내고, 서버에서는 json형태로 보내는 식의 분리보다는 json으로 보내든, 둘다 form-data식으로 보내든 하나로 통일한다. = URI가 플랫폼 중립적이어야 한다.