RESTful API 란?

현재 서비스 중인 어플리케이션 서버를 REST API 서버라고 막연히 그랬는데, 이 참에 제대로 정리를 할까한다.

엄밀히 말하면 우리 서버는 100% REST API는 아니고, RESTful 하려고 하지만 어떤 부분들은 포기한 route가 몇몇 있어서 섞여있다

REST는 Representational State Transfer의 약자이다. 기본적으로 개발방법론이나 철학에 가깝다.

REST는 http method로 보내는 Resource를 URI에 표현하는 것이 핵심이다. 이걸 해서 좋은 것은 계층화된 URI와 Resource, http method를 본다면 주석이나 특별한 설명 없이도 어떤 사람이 보든지 해당 route가 어떻게 동작하는지 알 수 있게 하기 때문이다.  이러한 통일성을 통해 다양한 영역의 개발자들이 HTTP를 이용할때 이해하기 편리하다는 장점이 있고 이것은 거대한 어플리케이션으로 갈 수록 뚜렷한 장점중 한 가지가 된다.

REST의 구성요소는 자원(URI), 행위(HTTP METHOD), 표현 으로 이뤄져있다.

클라이언트에서 URI를 이용해 자원을 지정하고 해당 자원에 대한 조작을 서버에 요청한다.

이 때 HTTP Method를 통해 액션을 표현하며 GET, POST, PUT, DELETE로 정의한다.

서버는 이러한 자원 및 행위 요청에 대해 응답하며, 여러 형태의 응답 데이터 형식을 가진다(JSON, XML등)

REST의 장단점은 아래와 같다.

장점

• HTTP 프로토콜 인프라를 그대로 사용
• HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용가능
• Hypermedia API의 기본을 지키며 범용성도 보장
• REST API 메세지가 의도하는 바를 명확히 나타내 파악이 쉽다
• 서버와 클라이언트의 역할을 명확히 분리한다

단점

• HTTP 메소드가 제한적이다(GET POST DELETE PUT)
• URI 표현에 있어서 서비스에 따라 한계가 있다

REST API 설계 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다

2. URI마지막 문자로 슬래시를 포함하지 않는다

3. 하이픈(-)은 URI 가독성을 높이는데 사용한다

4. 밑줄(_ )은 URI에 사용하지 않는다.

5. URI 경로에는 소문자가 적합하다.

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

7. 리소스 간에 연관관계가 있는경우엔 /리소스명/리소스ID/관계가있는 리소스명 형식을 권장한다

REST API 특징

1. 서버 - 클라이언트 구조 -> 자원이 있는 쪽이 서버, 요청하는 쪽이 클라이언트로 서로간 의존성이 줄어든다

2. Stateless -> HTTP 프로토콜은 Stateless Protocol 이므로 REST 역시 무상태성을 갖는다. Client의 context를 서버에 저장하지 않는다. 서버는 각각의 요청을 독립적으로 처리한다(이전요청과 다음요청이 연관되지 않는다)

3. 캐시 처리 가능 -> 캐시 사용을 통해 응답시간 감소, 성능, 자원이용률 향상이 가능하다.

4. 계층화 -> 클라이언트는 REST API 서버만 호출한다. REST SERVER는 순수 비즈니스 로직만 수행하고 앞단에 로드밸런싱, 암호화, 사용자 인증, 보안등을 더 설정하여 구조상 유연함을 추구할 수 있다. 네트워크 기반의 중간 매체 역시 사용가능하다.

5. 유니폼 인터페이스 -> URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. 특정 언어나 기술에 종속되지 않고 HTTP 표준 프로토콜에 따른 모든 플랫폼에서 사용 가능하다