REST API
REST 방식으로 서비스 API를 구현한 것
REST(Representational State Transfer) 방식
- 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미
- HTTP URL을 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
REST API 설계 예시
- URL은 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
- 마지막에 슬래시(/)를 포함하지 않는다.
- 언더바 대신 하이픈을 사용한다.
- 파일 확장자는 URL에 포함하지 않는다.
- 행위를 포함하지 않는다.
SOAP(Simple Object Access Protocol)
웹 서비스 상호작용에서 사용하는 XML 메시지 형식
일반적으로 HTTP 또는 JMS를 통해 전송되지만 다른 전송 프로토콜 사용 가능
메시지 구조
XML-RPC와 WDDX에서 envelope/header/body로 이루어진 구조.
Fault(결함)은 body(본문)의 하위 요소이며 오류를 보고하는데 사용된다.
SOAP Envelope
모든 SOAP 메시지의 루트 요소이며, 두 개의 하위 요소(옵션)를 포함한다. Header요소 및 필수 요소(Body)를 사용
SOAP Header
SOAP Envelope의 선택적 하위 요소이며, 메시지 경로를 따라 노드가 처리할 응용프로그램 관련 정보를 전달하는데 사용된다.
헤더의 바로 하위 요소를 헤더 블록이라고 한다.
- 헤더 블록은 애플리케이션 정의 XML 요소이고 송신자에서 최종 수신자로의 메시지 경로에서 발생할 수 있는 SOAP 노드에서 대상이 될 수 있는 데이터의 논리 그룹화를 나타낸다.
- 헤더 블록은 SOAP 중개 노드와 최종 SOAP 수신자 노드로 처리할 수 있다. 그러나 실제 애플리케이션에서는 모든 노드가 모든 헤더 블록을 처리하는 것은 아니다.
- 각 노드는 일반적으로 특정 헤더 블록을 처리하도록 디자인되고 각 헤더 블록은 특정 노드에 의해 처리된다.
SOAP 헤더를 사용하면 통신 당사자 간 사전 합의 없이도 분산 방식으로 SOAP 메시지에 기능을 추가할 수 있다.
SOAP Body
메시지의 최종 수신자를 위한 정보를 포함하는 SOAP Envelope의 필수 하위 요소이다.
- 본문 요소와 그에 연관된 하위 요소는 초기 SOAP 송신자와 최종 SOAP 수신자 간 정보를 교환하는데 사용된다. SOAP는 본문에 대해 하나의 자식 요소를 정의한다.
- <Fault>요소는 오류를 보고하는데 사용되고 다른 요소는 해당 요소를 사용하는 웹 서비스에 의해 정의된다.
- SOAP 결함(<Fault>요소) - 오류 보고에 사용되는 SOAP Body의 하위 요소이다.
- 결함 요소는 본문 항목으로 표시되어야 하고 본문 요소에 두 번 이상 표시되어서는 안된다.
- 결함 요소의 하위 요소는 SOAP 1.1에서와 1.2에서 다르다.
장점
- 기본적으로 HTTP 기반 위에서 동작하기 때문에, HTTP와 같이 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능
- 표준 Transport protocol인 HTTP 이외의 다른 Transport protocol들(SMTP)을 사용 가능
- 플랫폼 및 프로그래밍 언어에 독립적
- 간단하고 확장 가능하며, 멀티파트 MIME 구조를 사용하여 첨부를 통합하는 SOAP XML 메시지 지원
단점
- XML 포맷 형태로 보내기 때문에 다른 기술과 비교해 상대적으로 느리다.
- 최근 네트워크 속도의 비약적인 발전과 성능 최적화 기술의 발전으로 많은 부분이 해결되고 있음
DTLS(Datagram Transport Layer Security)
데이터그램 기반 응용 프로그램이 도청, 변조 또는 메시지 위조를 방지하기 위해 설계된 방식으로 통신할 수 있도록 하여 데이터그램 기반 응용 프로그램에 보안을 제공하는 통신 프로토콜
UDP에서 SSL 기술이 구현된 암호화 프로토콜
보안 프로토콜을 기술하고, 코드와 인프라의 재사용을 극대화하기 위해 TLS와 유사하게 설계된 DTLS가 제안되었다.
특징
손실에 민감한 메시징 - TLS의 트래픽 암호화 계층에서 손실 마취 메시지는 레코드와 독립적이지 않으며, 두 유형의 레코드 사이에는 의존성이 있다.
- DTLS는 명시적 시퀀스 번호를 추가하기 위해 TLS 레코드의 CBC 메커니즘을 빌린다.
HandShake에 대한 신뢰성 제공 - TLS는 메시지를 정의된 순서로 주고받아야하며 다른 주문은 오류이다. 또한 TLS handshake 메시지는 주어진 데이터그램보다 잠재적으로 커서 단편화 문제를 유발한다.
- DTLS는 이 두 가지 문제에 대한 해결책을 제공한다.
패킷 손실 - DTLS는 패킷 손실을 처리하기 위해 간단한 재전송 타이머를 사용한다.
- 서버가 재전송을 수신하면 재전송할 것임을 알고 서버는 타이머를 유지하고 타이머가 만료되면 재전송한다.
재주문 - DTLS에서 각 handshake 메시지는 handshake 내에서 특정 시퀀스 번호를 할당받는다.
- peer가 메시지를 수신하면 메시지가 다음 메시지인지 아닌지를 신속하게 결정할 수 있다. 해당 메시지가 처리되거나 이전 메시지가 모두 수신되면 이후 처리를 위해 대기열에 배치한다.
메시지 크기 - handshake 메시지는 상당히 클 수 있다.
- 단편화가 바람직하지 않으면 UDP 데이터그램은 종종 1500바이트로 제한된다.
- 이러한 한계를 보완하기 위해 DTLS handshake 메시지는 여러 개의 DTLS 레코드에 대해 단편화될 수 있으며 각 메시지는 짧은 오프셋과 짧은 길이를 모두 포함한다.
- 따라서, handshake 메시지의 모든 바이트를 소유한 수신자는 원래의 조각되지 않은 메시지를 재조립할 수 있다.
재생 검출 - DTLS는 레코드 재생 탐지를 선택적으로 지원한다.
- 패킷 복제는 반드시 악의적인 것은 아니지만, 라우팅 오류로 인해 재생 탐지가 선택 사항이다.
- 응용 프로그램은 중복된 패킷을 탐지하고 데이터 전송 전략을 변경할 수 있다.
