CS) RESTful API & HTTP 통신

Havi·2021년 8월 16일

CS

목록 보기

12/13

RESTful API

REST란 아키텍쳐 스타일의 제약조건을 모두 만족하는 시스템

REST아키텍쳐의 제약 조건

Client - Server
- server와 client의 역할을 분리
Stateless
- 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
Cache
- 같은 결과에 대해 캐싱을 해서 트랜잭션을 효율적으로 사용
Uniform Interface
1) Identification of Resources
- 자원은 유일하게 식별가능해야한다.
- URI나 RequestBody로 어떤 동작을 하는지 알려줘야함
2) Manipulation of Resources through Represenation
- xml, json등 한가지 타입으로 정의
3) Self-Descriptive Messages
- 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
4) Hypermedia As The Engine Of Application Sate
- 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.
Layered System
- 계층으로 구성이 가능해야한다.
Code-On-Demand(Option)

HTTP Method

서버와 클라이언트 사이에 이루어지는 요청과 응답 데이터를 전송하는 방식

종류는 다음과 같다.

GET
- 요청받은 URI의 정보를 검색하여 응답한다.
POST
- 클라이언트에서 서버에 데이터를 추가, 작성 함. 요청 데이터를 HTTP 바디에 담아 웹서버로 전송함
- 새로 작성된 리소스인 경우, 서버는 HTTP 헤더의 'Location:'에 URI 주소를 포함시켜 응답
- 행동(입력, 생성 등)하는 행위에 사용됨
PUT
- POST와 비슷한 방식이지만, PUT은 서버의 데이터를 갱신, 작성 함
- 리소스가 갱신되어도, 서버는 HTTP 헤더의 'Location:'를 보내지 않아도 됨.
- 서버는 클라이언트가 제시한 URI를 그대로 사용하는 것으로 간주 클라이언트서버 측 구현에 관여하는 것으로 POST를 더 많이 사용
PATCH
- PUT과 유사하게 해당 자원의 일부를 수정한다.
DELETE
- 요청된 자원을 삭제한다.
- 클라이언트 측에서 웹 리소스를 삭제할 것을 요청하는 메서드.
- 안전성 문제로 대부분의 서버에서 비활성
- delete는 body가 없어 한개의 데이터만 삭제가 가능함
- 여러개의 데이터 삭제 시 put 또는 patch 사용
- body 대신 path 파라미터로 데이터 전달
HEAD
- 메세지 헤더를 취득한다.
OPTIONS
- 제공하고 있는 메소드를 문의한다.

GET, POST 차이점

두 메서드 모두 서버에게 무엇인가를 요청할 때 사용하지만 GET 방식은 'URL ? 리소스' 형태로 서버에게 요청한다.

GET 방식은 간단한 데이터를 빠르게 처리할 수 있는 장점이 있지만 전송할 수 있는 리소스의 크기가 제한된다. 그 이유는 항상 URL를 포함시켜야 하기 때문에 URL 크기만큼의 공간이 사라지기 때문이다. 또한 리소스가 URL에 그대로 노출되기 때문에 보안상으로도 문제가 있다.

반면 POST 방식은 HTTP 헤더 뒤에 입력 스트림 형태로 리소스를 전송하는 방식으로 URL과 리소스를 별도로 전송하기 때문에 GET 방식보다 많은 데이터를 전송할 수 있으며, 최소한의 보안 유지에 효과가 있다. 최소한인 이유는 암호화를 하지 않는다면 보안이 거기서 거기이기 때문이다. 단점으로는 같은 리소스 양일 경우 get 방식보다 처리 속도가 느리다.