BOID

[iOS] 비연결 지향 통신(SOAP, RESTful 프로토콜 방식) - HoonIOS 본문

IOS 시작기

[iOS] 비연결 지향 통신(SOAP, RESTful 프로토콜 방식) - HoonIOS

HoonIOS 2021. 4. 30. 18:14

안녕하세요 HoonIOS입니다. :)

 

저번에는 서버와 앱이 끊기지 않고 계속 연결이 유지되어 있는 연결 지향 통신인 소켓 통신에 대해 포스팅을 해봤습니다.

boidevelop.tistory.com/80

 

[iOS] 연결 지향 통신이란?

안녕하세요. HoonIOS입니다. :) 이번 포스팅에는 앱에서 없을 수 없는 네트워크 통신에 대해 포스팅을 해보려고 합니다. 앱이 네트워크 통신을 하는 가장 큰 목적은 무엇일까요? 그것은 바로 앱의

boidevelop.tistory.com

앱에는 연결 지향 통신만 있는 게 아니겠죠? 필요할 때만 연결해서 통신을 하는 비연결 지향 통신도 있습니다. :)

 

대표적으로 HTTP, HTTPS등의 프로토콜을 이용해서 메시지를 주고받는 방식입니다.

 

비연결성 프로토콜은 요청이 들어오면 그에 맞는 응답을 보내주고 연결을 종료하는 방식으로 이루어져 있습니다.
따라서 소켓 통신과는 다르게 매 통신할 때마다 새롭게 연결을 해야 합니다.

 

이렇게 요청할 때마다 새로 연결을 따로 해야 돼서 소켓 방식에 비해서 상대적으로 데이터를 주고받을 때 속도에 제약이 있지만 쓸데없이 데이터를 주고받지 않는데 연결을 하고 있지 않아서 네트워크 자원을 줄일 수 있고 서버 부하를 방지할 수 있습니다.

 

비연결 지향 통신 프로토콜인 SOAP와 RESTful 프로토콜 방식에 대해 서령 해보겠습니다.

 

 SOAP 프로토콜 방식

 

SOAP는 Simple Object Access Protocol의 약자로 간단한 객체 접근 프로토콜이라는 뜻입니다.

 

HTTP, HTTPS, SMTP 등의 프로토콜을 통해 양쪽에 XML형태의 메시지를 주고받도록 구현된 프로토콜입니다.

 

원격 프로시저 호출이라고 불리는 클라이언트 - 서버 구조의 메시지 패턴을 많이 사용하고 있습니다. 이것의 통신 구조는 Envelope/ Header/ Body 3가지가 있습니다.

 

SOAP의 메시지 구조를 봐보겠습니다.

 메시지 구조

 

  • SOAP는 XML을 근간으로 헤더 부분과 바디 부분을 조합하는 구조의 디자인 패턴으로 설계가 되었습니다.
  • 헤더 영역 부분에는 반복이나 보안 및 트랜잭션을 정보로 하는 메타 정보를 처리합니다.
    (단, 헤더 영역은 선택사항으로 포함하지 않아도 됩니다. )
  • 바디 영역 부분에는 전달하고자 하는 핵심 내용, 데이터, 요구사항이 들어갑니다.

그럼 SOAP메시지 네트워크의 장점은 무엇일까요?

 장점

 

  1. SOAP를 사용한 HTTP는 기존 원격 기술들과 다르게  프락시나 방화벽과 상관없이 쉽게 통신을 할 수 있습니다.
  2. 이 통신 프로토콜이 사용하는 표준 전송 프로토콜은 HTTP이지만 이것뿐만 아니라 사용할 수 있는 프로토콜은 다양합니다.
  3. 프래그래밍 언어에 종속적이지 않아 제약이 없습니다.
  4. 매우 간단하고 편리합니다.
  5. XML을 이용하기 때문에 큰 양의 데이터를 교환할 때 이슈가 되지만 일반적인 크기에서는 문제가 없습니다.

 

이제는 통신에서 제일 많이 쓰고 중요한 RESTful 방식에 대해 알아보겠습니다.

 

 RESTful 프로토콜 방식

 

먼저 REST에 대해 알아보겠습니다.

 

RESTful의 근간이 되는 REST는 월드 와이드 웹(www)과 같은 분산 하이퍼 미디어 시스템을 위한 소프트웨어의 아키텍처의 한 형식입니다.

 

REST 자체는 웹 형식을 빌어 데이터를 전송하는데 별도의 전송 프로토콜 없이 전송하기 위해 만들어진 간단한 형식의 인터페이스로 네트워크 프로토콜은 아닙니다. 

 

REST의 데이터 구조는 간단합니다. 그냥 HTTP 프로토콜을 바탕으로 필요한 데이터를 별도 규약 없이 주고받기만 하면 됩니다.

 

음... 이것도 무슨 말을 모르시는 분들을 위해 더 단순화해서 설명하면 특정 웹페이지를 들어갈 때  입력하는 웹브라우저의 URL이라고 생각을 하면 됩니다.

데이터를 요청하는 URL을 네트워크를 통해 서버와 전달을 하면 서버에서 요구사항에 맞는 응답 데이터가 전송이 됩니다.

 

REST원리를 따라 구현된 시스템을 RESTful이라고 합니다.

 

이 시스템은 네트워크 서버에서뿐만 아니라 일반 웹서버에서도 약간의 설정만으로도 간단하게 구현을 할 수 있습니다.

 

RESTful은 서버에게 요청하는 정보를 URL을 통해서 나타나는데 요청 정보를 URL마다 슬래시로 구분을 할수 있습니다.

 

* 예를 들어서 한번 설명을 해보겠습니다. 

 

야구 정보를 얻고자 할 때 https://127.0.0.1/baseball URL을 얻는다고 가정을 해보겠습니다.

 

야구 정보에서 팀으로 정보를 알고 싶으면 아래처럼 계층 정보를 추가해줍니다.

 

https://127.0.0.1/baseball/Doosan 

https://127.0.0.1/baseball/Lottee 

https://127.0.0.1/baseball//SSG

https://127.0.0.1/baseball//LG 

 

물론 이건 그냥 예제를 통해 그냥 제가 정한 것입니다. 이건 iOS 앱 개발자가 스스로 맘대로 정하는 것이 아니라 서버 개발자로 이야기하고 서버 쪽에서 이렇게 설정을 해줘야 데이터를 제공받습니다.

 

서버 측에서 웹서비스나 콘텐츠의 성격에 따라 URL구성이 모두 달라질 수도 있고 주고받는 데이터 형식도 달라질 수가 있습니다.

따라서 데이터를 서버와 주고받기 위해서는 서버에서 요구하는 형식에 따라 요청 규격을 맞춰야 합니다. 

 

( 형식은 정해진 게 아니라 서버 개발자랑 협의를 하면서 결정하기 때문에 앱 개발자 마음대로 정하면 안 됩니다. )

 

RESTful API에서의 이제 대표 프로토콜인 HTTP 전송 방식을 한번 알아보겠습니다.

 

 RESTful API에서 HTTP 프로토콜

 

서버에서 요청하는 정보의 타입은 총 4가지로, 읽기, 쓰기, 수정, 삭제가 있습니다. 이것은 CRUD라고 부르기도 합니다.

 

CRUD는 Create, Read, Update, Delete의 첫 글자를 따서 정의한 것입니다.

 

가상으로 스케줄 등록을 위한 RESTful API가 있다고 생각을 하고 설명을 해보겠습니다.

스케줄에 대한 URL을 /schedule/list라고 정의를 한다면 CRUD처리를 하기 위해서는 URL뒤에 계층이 더 필요합니다.

 

예를 들어

/schedule/list/create

/schedule/list/read

/schedule/list/update

/schedule/list/delete

  • 이런 식으로 CRUD처리를 하기 위해서 URL계층이 더 필요합니다.

※ 참조

- URL 구성 권고에 따르면 URL에는 어떤 계층의 어떤 데이터라는 정보만 기재하는 것이 좋습니다. 

- 그 데이터를 읽을지 쓸지 수정할지 혹은 삭제할지와 같은 액션 구분은 URL에 나타내지 않는 것이 좋습니다. :)

 

 

 RESTful API에서 HTTP 메서드의 종류

 

메서드( 전송 방식 ) 목적
GET 특정 리소스의 정보를 요청
POST ID없이 리소스를 생성, 수정
PUT ID기반 리소스를 생성, 수정
DELETE 리소스 삭제
HEAD GET방식의 요청으로 내용없이 메타 정보만 요청
OPTIONS 특정 URL에 대한 보조 메서드 역할

 

  • 이 HTTP메서드에서는 대표적인 것은 GET, POST가 있습니다.
    1. GET
      - 데이터를 요청하는 메서드
      - 이 메서드는 데이터를 전송하기도 하지만 데이터를 요청하려면 URL뒤에 여러 코드를 작성해 복잡해질 뿐만 아니라 1024 바이트 이상의 정보를 전송할 수 없습니다.
    2. POST
      - 데이터를 전송하는 메서드
  • POST와 PUT의 차이는 식별자를 이용하는 것으로 PUT으로 통신을 보내면 식별자를 통해 해당 자원을 만들게 됩니다.
    POST는 request메시지의 엔티티를 통해 해당 자원을 만들게 된다고 합니다.

    이렇게 이해하면 이해가 잘 안돼서 어려운 점이 있는데 예를 들어 똑같은 것을 2번 요청한다고 하면 POST통신은 2개의 자원을 그대로 생성합니다.

    반면에,
    PUT통신은 똑같은것을 2번 요청한다고 가정을 하면 처음에 들어올 때는 해당 식별자의 자원을 만들지만 두번째 들어올때 똑같은 식별자가 들어오면 해당 자원을 생성하지 않고 교체를 하게 됩니다.
  • URL헤더에 이들 메서드를 사용해 동작을 정의하고 동일한 URL이라도 헤더에 처리된 메서드를 통해 처리할 액션을 각 다르게 구분을 할 수 있습니다.

 

이렇게 통신 프로토콜에 대해 알아봤습니다. 각 메서드를 통해 정보를 요청하기도 하고 데이터를 전송해서 수정하기도 합니다. 상당히 중요한 메서드 이므로 각 메서드 별 역할을 잘 구분해야 될 거 같습니다.

다음에는 통신에서 보내는 데이터 포맷에 대해 알아보겠습니다 :)

반응형
Comments