REST Api

REST란??

Representational State Transfer의 약자로 자원을 이름으로 구분하여 자원의 상태 정보를 주고받는 방식(주로 JSON, xml).

HTTP URI를 통해 자원을 명시하고 HTTP Method(GET, POST, PUT, DELETE)를 통해 자원에 대한 CRUD 기능을 적용.

이는 네트워크에서 서버와 클라이언트가 통신하는 방식 중 하나이다.

REST의 필요성

1. 어플리케이션 분리 및 통합
2. 다양한 브라우저와 안드로이드, IOS 등 모바일 기기와도 통신해야 함.
3. 멀티 플랫폼 지원을 위해 서비스 자원에 대한 아키텍쳐를 세울 때 유용

REST의 구성 요소

1. 자원 - Uri
   모든 서버의 자원에는 고유한 ID가 있으며 이를 HTTP URI로 표현한다.
   클라이언트는 URI를 통해 자원을 지정하고 해당 자원의 상태 조작을 서버에 요청한다.

2. 행위 - HTTP Method
   GET, POST, PUT, DELETE 메소드를 제공하여 행위를 나타낸다.

3. 자원의 표현
   클라이언트가 자원에 대한 조작을 요청하면 그에 대한 응답을 보낸다.
   자원은 JSON, XML, TEXT 등 여러 형태가 가능하다.

REST의 특징

1. Server-Client 구조
   자원을 가진 쪽이 Server, 요청하는 쪽이 Client

2. Stateless
   Client의 context를 서버에 저장하지 않음.
   Server는 각각의 요청을 독립적인 것으로 인식함 (DB 수정에 의한 변화 제외하고 이전 요청이 다음 요청에 영향 X).

3. Cacheable
   HTTP의 캐싱 기능을 적용할 수 있다.
   응답시간이 빨라지며 성능의 향상을 도모할 수 있다.

4. Layered System (계층화)
   REST Server는 비즈니스 로직 계층 외에 보안, 로드 밸런싱, 암호화 등 계층을 추가해 유연하게 사용할 수 있다.

REST API

REST를 기반으로 API를 구현한 것.

REST의 장점을 적용하여 시스템을 분산해 확장성과 재사용성을 높여 유지보수에 유용하다.

또한 HTTP를 지원하는 모든 언어로 클라이언트와 서버를 구현할 수 있다.

REST API 설계 규칙

기본 규칙

1. Uri로 자원 정보를 표현한다.
   ex) GET /members/1

2. 자원에 대한 행위는 HTTP Method로 표현한다
   단, 메소드 이름이나 동작이 들어가지 않도록 주의
   ex) GET /members/show/1 GET /members/delete/1

규칙

1. /(슬래시)는 계층 관계를 나타냄
   ex) http://~~~/houses/apartments

2. Uri 마지막에 /를 붙이지 않음.

3. 가독성을 위한 '-'는 사용 가능하나 '_'는 피함

4. Uri 경로를 소문자로.

5. 파일 확장자는 Uri에 포함하지 않음.

RESTful Api

REST원리를 따르는 Api를 의미한다.

이해도를 높이고 호환성이 좋도록 할 경우 RESTful Api를 구현하는 것이 좋다

RESTful하지 못한 Api의 예시는 다음과 같다.

• CRUD 기능을 모두 POST로 처리하는 Api
• 자원 경로에 resource, id 외의 정보가 들어가는 Api