HTTP는 크게 요청과 응답으로 나눌 수 있다
각 메시지는 라인 - 헤더 - 바디 세 부분으로 구성된다.
라인 : http 메시지의 맨 첫 줄에 해당하는 영역으로 메시지의 가장 기본적인 내용인 응답/요청 여부, 메시지 전송 방식, 상태 정보 등이 작성되는 곳.
헤더 : 메시지 본문에 대한 메타 정보
바디 : 실제로 보내고자 하는 메시지 본문 내용
실제 메시지 샘플을 살펴보면서 http에 대해서 알아보자.
흔히 request라고 부르는 요청 메시지는 get/post 부르는 이 요청 메시지는 get/post 등의 전송 메소드를 정의하는 데에서 시작.
뒤이어 작성되는 것은 요청 내용에 대한 경로, 그 다음은 요청 형식에 대한 버전 정보.
즉, 어떤 버번의 http 문법을 준수하고 있는가에 대한 것. 여기가 첫 라인에 해당
라인 아래에 작성된 내용은 한 줄 공백이 나오기 전까지는 모두 헤더임.
헤더는 모두 키 : 값으로 이루어 진다는 공통점이 있음.
샘플에서는 host헤더와 content-type헤더가 정의되어 있다.
이때 host 헤더에는 도메인 및 포트 번호가 포함되어 있는데 이는 두 개 이상의 도메인에 연결되어 있는 서버일 경우 어느 도메인으로 요청이 들어왔는지 구분하기 위함.
이어지는 content-type는 메시지 본문이 어떤 형식으로 작성되어 있는지를 나타낸다. 샘플에서는 apllication/x-www-urlencoded 값이 사용되고 있는데 이는 우리가 알고 있는 일반 post 방식으로 데이터를 전송한다는 것을 의미
회원가입이나 로그인, 게시판 글쓰기 등 많은 ui들이 대부분 이 방식을 사용해서 서버로 값을 전송한다. 참고로 우리가 api연동을 위해 사용할 메시지는 json형식인데, 이때는 content-type 헤더의 값을 application/json으로 설정해 주어야 한다. 그렇지 않으면 서버에서는 메시지 본문을 제대로 해석하지 못할 수도 있다.
한줄 공백 아래에 작성된 메시지 본문의 형식은 헤더의 content-type에 설정된 타입과 일치해야 한다. 가령 샘플 예제에서 전송하고자 하는 account,passwd,grant_type 3개를 x-www-form-urlencoded 타입으로 전송하려면 이들 데이터를 '&'로 연결하여 메시지 본문에 넣어야 한다.
ex) account = lgvv.rldd.com&passwd = 1234&grant_type = password
여기서 x-www-form-urlencoded타입은 여기에다 한가지 처리를 더 적용하는데 바로 특수문자의 경우 URLEncoding형식으로 변환한다.
URLEncoding 형식이란 URL전송에서 사용되는 @,& 등의 특수 문자가 전송하려는 값 내에도 폼함되어 있을 때, 이를 겹치지 않는 다른 특수문자 형식으로 변경하는 것을 의미.
ex)
song=soundOfSilence
singer = simon&garfunkel
이 값은 &으로 연결하면
song=soundOfSilence&singer = simon&garfunkel // HTTP 메시지의 본문에 들어가는 형태
그런데 이 값을 그대로 서버에 전송한다면, 이 값을 받은 서버는 '&'문자를 기준으로
song=soundOfSilence
singer = simon
garfunkel
로 분리해 버리게 된다.
이렇게 분리되면 문제가 발생하겠지?
따라서 이를 방지하기 위해 x-www-form-urlencoded 타입은 잘못 해석될 우려가 있는 '&'문자를 '%26'이라는 값으로 변경하여 전송
이렇게 전달된 값은 다시 서버에서 URLDecoding이라는 역변환 과정을 거쳐 다시 '&'으로 처리된다.
브라우저나 일부 툴의 경우애는 이 같은 처리를 자동으로 해주지만, 수동으로 HTTP 메시지를 작성하는 경우에는 URLEncoding 처리를 직접 해 주어야 하므로 주의해야 합니다.
다음은 post 가 아닌 get 방식으로 바꾼 결과다
메시지 본문이 사라지고, 본문에 있어야 할 값이 첫 번째 라인의 경로 뒤에 '?' 문자열과 함꼐 연결되었다.
get 방식에는 파라미터를 모두 URL 뒤에 연결해서 전달하기 때문이다. 이렇게 연결된 파라미터는 쿼리 스트링 이라고 부른다
메시지 본문을 사용하지 않기 때문에 get 방식에서는 content-type 헤더가 사용되지 않는다. 또한 브라우저에서는 url 뒤에 쿼리 스트링만 연결하면 되므로 비교적 간결하게 정보를 전달할 수 있다는 장점이 있다.
하지만 url 뒤에 쿼리 스트링만 연결하면 되므로, 비교적 간결하게 정보를 전달할 수 있다는 장점이 있다.
하지만 url 경로는 1024 byte까지만 허용되기 때문에, 긴 값을 get 방식으로는 전송할 수는 없습니다. 데이터를 전송하는 경우보다는 필요한 정보를 요청할 때 주로 get 방식이 사용됩니다.
참고로 이렇게 바꾼다고 해서 서버에서 정상적으로 응답할 수 있는 것은 아니다. 어디까지나 서버에서 get 방식의 요청을 허용해 주어야 제댈 응답받을 수 있다.
일반적으로 웹 브라우저는 get/post 두가지 방식만 지원하지만 RESTful API는 더 다양한 형식의 http 메소드를 사용한다
그렇다면 HTTPS는 무엇일까?
앞에서 사용한 메시지들은 모두 평문 그대로 전송하기 때문에 누군가 패킷을 훔쳐보는 스니핑 공격에 취약하다. 다시 말해 주고받는 데이터가 제 3자에게 공개될 수 있다는 것
이 떄문에 금융이나 개인 정보 교환처럼 서버-클라이언트 메시지가 보호될 필요가 있을 떄에는 인증서를 통해 패킷을 암호화한 다음에 전송하게 되는데, 이를 가리켜 HTTPS라고 부른다. HTTP+S(Security)가 합쳐진 단어로 여기에 적용되는 보안 인증에는 SSL 인증, 또는 TLS인증 등 다양한 버전이 존재한다.
HTTPS 인증의 핵심은 메시지를 암호화한 후 전달함으로써, 중간에 데이터를 훔치더라도 열어볼 수 없도록 보호하는 것에 있다.
HTTPS 통신은 단순히 HTTP 통신 프로토콜에 'S'를 붙인다고 지원되는 것이 아니라 보안 통신을 위한 인증서를 준비해서 이것을 서버에 설치해 주어야 한다. 신뢰성있는 인증서는 인증기관에서 발급받을 수 잇는데, 대부분 유료. 따라서 보안 통신을 하고 싶다면 적절한 수준의 인증서를 구매하여 도메인 또는 서버에 적용해 주어야 한다.
일단 HTTPS 프로토콜이 설정되고 나면 앱 개발자나 서버 개발자가 해야할 일은 많이 않다. 그냥 HTTP 통신하듯이 작성해서 전송하기만 하면 된다. 단, 전송 시 프로토콜을 HTTPS로 변경해야 한다는 점은 잊지 말아야 한다.
애플은 2016년 10월 이후 앱 스토어에 등록되는 모든 앱에서 HTTPS 프로토콜을 통한 네트워크 통신만 허용
ATS 설정을 변경하여 HTTP 프로토콜로도 통신을 할 수는 있지만 앱 스토어에 등록할 경우 반드시 HTTPS 프로토콜만 사용할 수 있기 때문에 서버와 연동하는 앱을 제작하는 경우에는 미리 인증서를 발급 받아 준비해야 한다.
RESTful API란?
Representational State Transfer의 첫 글자를 딴 것으로 HTTP를 위한 아키텍처의 한 형식이다. 엄격한 기준에서 봤을 때 REST는 네트워크 프로토콜은 아니다. 단지 네트워크 자원을 정의하고 자원에 대한 주소를 관리하는 방법일 뿐이다. 쉽게 말해 REST란 웹 콘텐츠나 데이터를 HTTP기반으로 간단히 주고 받기 위해 정의된 간단한 형식의 인터페이스를 말한다.
REST의 구조는 굉장히 간단하다.
클라이언트-서버 구조에 리쿼스트/리플라이 형식과 비슷하다.
이렇게 REST구조를 따라서 구현된 시스템을 우리는 RESTful API라고 부른다. RESTful 시스템은 네트워크 서버를 통해서 뿐만 아니라 일반 웹 서버를 통해서도 약간의 설정만으로 쉽게 구현할 수 있다는 장점이 있어 널리 확산되는 중.
RESTful 시스템은 데이터를 전송하거나 받기 위해 요청 형식을 명확히 정의해야 한다. 이때 요청 형식은 표준이 정해져 있지 않으며, 서버와 클라이언트 간에 어떤 식으로 데이터를 주고 받을 것인지 서로 협의하는 데에 따라 달라진다. RESTful 기반으로 서버에서 요청과 응답을 주고 받을 수 있도록 정의된 형식을 RESTful API라고 한다.
RESTful API에서 주고받는 내용들은 모두 HTTP 메시지의 본문에 담겨서 전달됩니다. 특히 RESTful API는 메시지 본문을 JSON형식으로 구성하여 보내기 때문에, RESTful API는 메시지 본문을 JSON형식으로 구성하여 보내기 때문에 RESTful API 통신을 위해서는 JSON 형식을 잘 알고 있어야 한다.
(후기)
수업에서 배운 내용이나 실 적용을 위해 더 공부가 필요할 듯 하다.
다음은 JSON파일에 대해서 다시 정리해보는 시간을 갖도록 하자.
'Archive > 꼼꼼한 재은씨 시리즈' 카테고리의 다른 글
[iOS14] ATS와 관련하여 (0) | 2021.04.23 |
---|---|
JSON 학습정리 (0) | 2021.04.23 |
[iOS14] SearchBar - 검색바 사용 (0) | 2021.04.13 |
CoreData 코드 리뷰 (0) | 2021.04.09 |
이벤트 버블링과 리스폰더 체인 (0) | 2021.04.09 |