REST API에 대해서(1) 개념과 적용

정지은·2022년 12월 1일

네트워크

이론

목록 보기

1/2

이번 포스트에서는 REST API를 설계하는 방법이 아닌, 기초 개념과 사용법을 위주로 정리하였다. 예시는 Django기반의 프로젝트 실행 로그를 캡쳐해왔다.

0. REST API란

0-1 . API

API는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한다. 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 할 수 있다.(출처)

0-2 . RESTful API

Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처라고 한다. 의미를 설명하자면 웹에 존재하는 모든 자원(이미지, 동영상, DB)에 고유한 URL을 부여하여 활용하는 구조로, 자원을 정의하고 그 주소를 지정하는 방법론이라고 할 수 있다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있다.

여러 가지 API중 REST의 스타일을 따르는 API를 REST API라고 부른다.

1. 구성요소

자원(Resource): URI
행위(Verb): HTTP Method(GET, POST, DELETE, PUT)
표현(Representation of Resource) : JSON, XML, TEST, RSS

2. 특징

https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints

Client–server architecture
영역을 클라이언트와 서버로 분리한다. 이로서 서버가 처리해야 할 일이 줄고, 확장이 용이하게 된다. 하나의 데이터를 여러 플랫폼에서 보여주어야 할 때 더욱 유용해진다.
Statelessness
서버는 클라이언트에 대한 사전 정보나 클라이언트의 상태를 저장하지 않는다. 즉, 클라이언트의 상태 변화는 서버가 관여하지 않고 오로지 클라이언트단에서 해결한다. 그러므로 서버로 요청을 보낼 때에, 서버가 해당 요청을 처리하기 위해 필요로하는 모든 데이터를 전부 보내 주어야 한다.
Cacheability
응답과 요청 모두 캐싱 처리가 가능한지에 대해 명시해야 한다. 가능하다면 클라이언트 단에서 캐시를 저장해 둔다.

ajax의 경우, cache옵션의 default value는 true이다.
Layered system
클라이언트 입장에서는 자신과 직접적으로 연결된 부분만 신경쓰면 된다. 이외의 부분은 알지 못한다(바로 끝단의 서버와 연결되어 있는지, 중간의 프록시나 로드 밸런서와 연결되어 작동하는지 알 수 없음.)
Uniform interface
ㄱ. Resource identification in requests : 각 리소스는 RESTful API의 url같은 것을 통해 전달된다. 그 리소스들은 클라이언트 단에서 보여지는 것들과는 개념적으로 분리되어있다(서버는 데이터들을 실제 저장된 형태가 아닌 JSON, XML등의 형태로 바꾸어 전송한다.)
ㄴ. Resource manipulation through representations : 클라이언트가 리소스의 표현(representation)만 가지고 있더라도 이를 이용하여 실제 리소스의 상태를 변경시킬 수 있다.
ㄷ. Self-descriptive messages : 각 메시지에는 그 메시지를 처리하는 방법에 대한 충분한 정보가 포함되어 있다. 예를 들어, 어떤 파서를 사용해야 하는지 media type으로 지정한다.
ㄹ. Hypermedia as the engine of application state (HATEOAS) : 초기 URI로 REST 서비스에 접근했다면, 클라이언트는 서버에서 제공하는 링크를 이용해 동적으로 리소스에 접근할 수 있어야 한다. 클라이언트 단에서는 서버 단의 처리내용을 저장해두지 않아도 된다.

3. 장점

확장성
REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기를 조정할 수 있다.
유연성
완전한 클라이언트-서버 분리를 지원하므로, 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다.
독립성
REST API는 사용되는 기술과 독립적이다. 서버와 클라이언트 어느 쪽이 무슨 언어를 사용하든 API통신에는 영향이 없다.

4. HTTP Method

POST
서버에 데이터를 전송한다. 이 때 보낼 데이터도 함께 포함해 보내야 한다. 동일한 요청을 여러 번 보내면 같은 리소스가 여러 개 생겨나는 경우도 있다. 새로운 자원을 추가할 때 사용한다.
GET
서버의 지정된 URL에 있는 리소스에 접근한다. 자원을 받아오기만 할 때 사용한다.
자원의 상태를 변화시키기 않으므로 safe method라고도 불린다.
PUT
서버의 기존 리소스를 업데이트한다. POST와 달리 여러 번 동일한 요청을 보내도 결과는 동일하다. 존재하는 자원을 변경할 때에 사용한다. 변경할 리소스가 존재하지 않을 경우, 새 리소스를 생성하며 201을 리턴한다.

POST와 PUT의 차이점
POST는 여러 개의 자원에 수행되지만, PUT은 단일 자원에만 수행된다.

DELETE
리소스를 제거한다. 서버의 상태를 변경할 수 있는 메소드이므로, 사용자는 적절한 인증 절차를 거쳐야 한다. 자원을 삭제할 때 사용한다.

5. 적용 예시: ajax를 통한 호출

ajax
비동기 자바스크립트와 XML (Asynchronous JavaScript And XML)의 약자. 서버와 통신하기 위해 XMLHttpRequest 객체를 사용하는 것을 말하며, JSON, XML, HTML 그리고 일반 텍스트 형식 등을 포함한 다양한 포맷을 주고 받을 수 있다.

    function writeFeed(fd) {
        $.ajax({
            url: "/content/upload",
            data: fd,
            method: "POST",
            processData: false,
            contentType: false,
            success: function (data) {
                console.log("성공");
            },
            error: function (request, status, error) {
                console.log("에러");
            },
            complete: function() {
                console.log("무조건실행");
                closeModal();
                location.reload();
            }
        })
    };

실행결과

HTTP/1.1 : 리소스를 가져오는 프로토콜인데 그 버전이 1.1이라는 의미.
200 : 상태코드 값. 정상처리되었다.
맨 뒤에 붙은 숫자는 아파치 정책에 따른 Content-length값이라고 한다.

6. HTTP 상태코드

1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다.
2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.
3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요합니다.
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.
5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.

200 클라이언트의 요청을 정상적으로 수행
201 클라이언트가 리소스 생성을 요청해서 성공적으로 생성됨(POST, PUT에 대한 응답)

400 클라이언트의 잘못된 문법. 서버가 이해할 수 없음.
401 클라이언트의 인증되지 않은 요청.
403 권한이 없는 클라이언트가 접근을 시도함.
404 (not found)서버가 요청받은 리소스를 찾을 수 없음.

500 서버에 문제 발생
502 (Bad Gateway) 서버가 게이트웨이로부터 잘못된 응답을 수신