REST API? REST API!

완성된 REST API 프로젝트를 직접 만지고 수정하면서 조금 더 짜임새 있고 효율적으로 활용 및 수정하고 싶다는 마음에 이렇게 한 번 제대로 REST API를 파헤쳐보려고 한다.

REST

REST는 Representational State Transfer의 약어로서 웹의 장점과
HTTP의 우수성을 제대로 활용할 수 있는 아키텍처이다.
HTTP URI를 통해서 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해서
명시된 자원의 CURD 연산을 적용하는 것을 의미한다.

자원을 이름으로 구분해 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

** REST가 필요한 이유? **

다양한 클라이언트를 이용해서 사용할 수 있고 통신 할 수 있기 때문에 (멀티 플랫폼)
분산 시스템, 모듈/기능 별로 분리하기 쉬워지고 모듈 => 애플리케이션 상호 통신을 원활하게 이루어 짐

** REST의 구성 요소 **

자원(Resource): URI주소(ex: 192.168.0.1/main)
행위(Verb): HTTP Method 프로토콜
표현(Representation of Resource) : JSON, XML과 같은 형태의 Representation 데이터

REST API의 특징

Uniform Interface(인터페이스 일관성)

URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

Layered System(계층화)

REST 서버는 다중 계층으로 구성이 가능하고 보안,로드밸런싱, 암호화, 사용자 인증을 추가해 구조상 유연성을 줄 수 있다. 그리고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.

Stateless(무상태)

HTTP 프로토콜을 사용하는 REST는 무상태성을 가진다.
클라이언트의 요청을 서버에 저장하지 않기 때문에 정보(쿠키,세션)을 신경 안쓰고 처리 할 수 있기 떄문에 구현이 단순해진다.

Cacheable(캐시 처리 가능)

웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.

Server-Client(서버-클라이언트 구조)

자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 되어 각 역할이 구분되기 때문에 서로 간의 의존성이 떨어짐

Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
Client: 사용자 인증이나 상태 정보 등을 직접 관리하고 책임진다.

REST의 장단점

장점

HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
서버와 클라이언트의 역할을 명확하게 분리한다.

단점

표준이 존재하지 않는다.
사용할 수 있는 메소드가 4가지 밖에 없다.
HTTP Method 형태가 제한적이다.
구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
PUT, DELETE를 사용하지 못하는 점 (보안 이슈가 가장 크다고 알고 있다.)

REST에서 사용하는 HTTP METHOD?

GET : 지정된 URL에서 리소스의 표현을 조회
POST : 지정된 URL에 신규 리소스를 생성
PUT : 지정된 URL에 리소스를 생성하거나 업데이트
DELETE : 지정된 URL의 리소스를 제거

REST API의 개념

What mean API?

API(Application Programming Interface)
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램 서로 정보를 교환이 가능 하도록 만드는 것을 의미

REST API?

REST 기반으로 서비스 API를 구현한 것 즉 API를 REST형식으로 만든 것을 의미한다.

REST API의 특징

REST 기반으로 시스템을 분산하여 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.

REST API 설계 규칙

1. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.
3. 밑줄(_ )은 URI에 사용하지 않고 가독성을 높이기 위해 하이픈(-)만 사용한다.
4. URI에 대문자는 적지 않도록 한다.(소문자가 좋아요 :) )
5. URI에 확장자명은 적지 않는다.
6. 계층 관계는 / 를 이용해서 표현한다 /name
   /name/a
   /name/a/adam

자원에 대한 행위는 HTTP Method를 이용해서 표현한다.

잘못된 예
POST /name/create (이름 추가하기)
GET /name/a/get (이름 가져오기)
POST /name/a/update (이름 수정하기)
DELETE /name/a/delete (이름 삭제하기)

올바른 예
POST /name/a (이름 추가하기)
GET /name/a (이름 가져오기)
PUT /name/a (이름 수정하기)
DELETE /name/a (이름 삭제하기)

HTTP 응답코드

HTTP 상태 코드 모음