ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • HTTP 통신
    개발상식/서버통신

    안녕하세요.

     

    이번 카테고리는 연습 및 학습 용도 이며

     

    다시 보기 위함 + 한번 더 학습한걸 복습하기 위한 용 입니다.

     

     

    평소 unity 프로젝트 영상이나 호기심 가는 기능 구현을 찾아 본다던가

     

    c# 문법 책을 찾아 보면서 공부를 하고 있었는데,

     

    우연히 서버 관련한 글을 보게 되었습니다.

     

     

    unity 엔진이나 c#의 다양한 기능 구현도 제대로 하지 못하는데,

     

    서버 관련해서 찾아 보려니 갑자기 난이도가 몇배는 올라간 느낌 이였습니다..

     

     

    머릿속이 순간 하얘지긴 했는데, 새로운걸 학습 한다고 생각하니 흥미가 생기기도 하고ㅎㅎ

     

    빠르진 않더라도 천천히 한걸음씩 차곡차곡 나아간다는 생각으로

     

    학습한 내용들을 정리하도록 하겠습니다.

    (학습된 내용이나 제가 이해한 내용이 잘못 될 수도 있음)

     


    우선 제가 학습한 글은

     

    API와 HTTP의 간단한 개념(?)에 대해 설명을 해주고 있었습니다.

     

     

    용어가 생소 하기도 하고.. 

     

    서버랑 관련되면 난이도가 높아 질 수밖에 없다는데요..

     

    레스트풀 API나 통신법에 대해 더 학습하다 보면 더 어려워질수밖에 없지만

     

    천리 길도 한걸음 부터라는 말이 있듯이 

     

    그 중에서 그나마 쉬운(?) 편에 속하는 HTTP통신에 대한 개념과 함께

     

     

    공개된 API를 이용하여 해당 서버에 정보를 요청하고

     

    응답 받은 것을 HTTP 통신으로 구현하는 과정을 살펴 보겠습니다!

     


     

    *API는 정보를 요청하면 결과를 받는 웹 사이트 라고 보면 되고

     

    *HTTP 통신 은 비동기적인 통신 이라고 이해하면 된다고 합니다.

     

     

    온라인 게임처럼 여러명이 실시간 소통하는 서버가 아니라

     

    각각의 PC에서 따로따로 필요한 정보만 웹 서버에 요청 하면 웹 서버에서 응답을 보내주는 비동기적인 서버 통신이라고 하는데요

     

    음.. 글로만 설명을 보니 이해가 완벽하게 안되지만..

     

    기능 구현과 함께 실습 하는 과정을 보며 몸에 익힘과 더불어 이론을 배워가 보겠습니다.

     


    우선 이 *API 는 거의 웬만한(?) 게임 사이트들은 API 사이트를 공개해 두고 있다고 합니다.

     

    누구나 쉽게 접근해서 정보를 얻어 올 수 있다고 하는데

    (그럼 API가 공개 되지 않은 경우는, 공개를 안 해 둔건가?? 라는 궁금증이 들었는데..)

     

    1) private API
    : private API는 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행합니다. 따라서 제 3자에게 노출되지 않습니다.

    2) public API
    : public API는 개방형 API로, 모두에게 공개됩니다. 누구나 제한 없이 API를 사용할 수 있는 게 특징입니다.

    3) partner API
    :partner API는 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있습니다. 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용됩니다.

     

    등등이 있다고 하며.. 잠시 이 의문은 접어 두어야 겠습니다.


    다시 다른 길로 세지 않고 본론으로 돌아와..

     

    이 OPEN API를 활용하여

     

    특정 게임의 전적 사이트 같은 경우 이를 활용하여 구현이 되어 있다고 하는데

     

    역시.. 게임으로 예를 들으니 쉽게 이해가 갔습니다..

     

    공개된API를 찾아 보는 방법은 매우 쉬웠는데요

     

    위 사진 처럼 던전앤파이터 API를 검색하여 

     

    상단에 있는 "던전앤파이터 API Docs"를 들어가 보면

     

    서버정보 / 경매장 시세 / 캐릭터 '기본 정보' 등등..

     

    다양한 게임 정보를 받아 올 수 있었습니다.

     

    이러한 정보 들을 요청하고 응답을 받을 수 있는게

     

    *API 라는데!

     

    오...

     

    지식 +1 됐습니다..

     

    이 후도 따로 어려운건 없었고

     

    회원 가입을 통하여 어플리케이션을 등록 하면

    이 api key가 발급이 되는걸 볼 수 있었고

     

    이 key를 사용하여 

     

    던전앤 파이터 api를 사용 할 수 있었습니다.


    그렇다면 이제 HTTP 통신!!

     

    이 통신하는 방법에는 2가지가 있다고 합니다.

     

    WWW 방식과 / UnityWebRequest 방식 두가지 였는데요

     

    우선 이번 학습한 글에는 UnityWebRequest 방식 이며

     

     

    WWW 방식에서 할 수 있는 구현이 UnityWebRequest 에서는 모두 할 수 있다고 하며

     

    UnityWebRequest 가 좀 더 최신의 방식 이라고 합니다.

    (두 개 모두 뭐가 뭔지....)

     

    취업 및 시간이 조금 지난 소스코드를 보면 WWW 방식 도 많기에

     

    WWW 방식도 할 줄 알아야 하고 할 줄 아는게 당연히 좋겠지만

     

    우선은 이 UnityWebRequest란 녀석 부터 살펴 보겠습니다.

     

    + 한가지 더

     

    HTTP 통신을 할 때 의 방식도 2가지가 있다고 하는데요.

     

    GET 과 POST 가 있으며 다른 것들도 존재 하지만

     

    대표적인것이 GET 과 POST 방식 이라고 합니다.

     


     

    마지막으로 HTTP 통신을 할 때 주의사항!

     

    * 코루틴을 사용 해야 함.

    * using문을 사용하는 경우가 있다.

     

    두가지 정도로 대표적으로 볼 수 있다고 하는데요

     

    코루틴을 사용 해야 하는 이유는 비교적(?) 단순 했습니다.

     

    HTTP 통신을 그냥 스크립트에 쓰게 되면

     

    요청을 보내고 거기서 처리한다음 응답이 돌아오는데 까지 시간이 걸리는데

     

    이 시간지연이 발생 할 때  코루틴을 쓰지않고 그냥 스크립트를 쓰게되면

     

    지연된 시간만큼 프로그램이 멈추게 된다고 합니다.

     

     

    프로그램이 멈추게 되는건 치명적인 오류기 때문에

     

    반드시 코루틴을 이용해 지연시간을 없애야 한다고 하며

     

     

    두번째로 

     

    USING문을 사용하는 경우가 있다.

     

    이 부분은 웹 서버를 통해서 다양한 리소스들이 왔다갔다 할텐데

     

    USING문을 사용하게 되면 

     

    이 리소스들을 필요없이 자동으로 알아서 디스포저 해주기 때문에

     

    자원관리에 용이해 진다고 합니다.

     

    그래서 USING문을 사용하는 경우가 종종 있다고는 합니다.

     


    이제! Unity를 통해서 기능 구현 과정을 살펴 보겠습니다.

     

    우선 스크립트를 Network라는 이름을 지어 만들어 주었습니다.

     

    UnityWebRequest 를 사용 할 것이기에

     

    이를 사용 할 수 있는 UnityEngine.Networking을 선언해 주는 모습이며

     

    통신을 할 거면 우선 주소가 필요하기에

     

    api 사이트의 주소를 Update 함수가 아닌

     

    코루틴 함수에 넣어 주었습니다.

     

     

    ckIvOVxv7Ub1tOhC7LZtdlgFc0vrs6mv 이 값이 본인의 키와 동일 한 것을 알 수 있는데

     

    상황 상 여러명이 사용해야 해서

     

    이 api의 키가 계속 바뀌어야 된다면

     

    이런 식으로 apiKey를 Update 할 수 있다고 합니다.

     


     

    다시 돌아와서 통신을 할 주소는 정했으니

     

    통신을 어떻게 하느냐가 중요 한데

     

    UnityWebRequest 방식의 get을 이용하여 가져와 주는 모습이며

     

    변수 이름은 관례적(?) 으로 www를 사용한다고 합니다.

     

    UnityWebRequest 의 Get 방식으로 요청을 보내는 코드 이며

     

    이 요청에 응답이 될 때까지 기다려야 하는데

     

    제어권을 넘겨주는 yield와

     

    이름만 봐도 추상 할 수 있는 SendWebRequest()

     

    즉, 보낸것에 응답이 올때까지 기다리겠다는 코드를 작성해 주었습니다.

    이 응답을 받는 경우는 2가지가 있을텐데

     

    한가지는 정상적으로 응답이 온 경우,

     

    다른 한 가지는 에러가 났을 경우 입니다.

     

    그렇기에 if문을 통해 조건을 걸어 주었습니다.

     

    응답을 받아온 것을 다운로드 해놓은 downloadHandler를 사용하여

     

    text로 보여주는 error가 null이 아닐시와

     

    반대로 error가 null이라면 정상적으로 받아오지 못한 것이니

     

    "Error"라는 텍스트를 보여지게 해 주었으며

     

    StartCoroutine() 으로 코루틴을 실행해 주는 모습 입니다.

     

    Test라는 빈 오브젝트를 하나 생성해 주어 NetworkTest 스크립트를 입혀 주었으며

     

    실행을 해 주니 else 문에 있던 "Error" 표시가 안 떴으니 정상적으로 통신 응답을 받은 것이고

     

    카인/디레지에/시로코 등등.. 

     

    다양한 서버 정보의 응답을 받은 것을 볼 수 있었습니다.

     

    이번에는 url 주소를 직업 정보로 바꿔서 해 봤는데요

     

    와우...

     

    옛날에 했을때엔 이전엔 귀검사/격투가/마법사/런처 4개 직업으로

     

    각 전직이 가능하며.. 레인저가 데스페라우(?) 승급이 나온다고 했었을때가 엊그제 같은데..

     

    직업이 상당히 많이 나온것 같습니다.

     

    그리고 api 사이트를 찾아 보다 보면

    이러한 요청변수 항목이 존재 하는데

     

    하나 하나 해석하면 생각보다(?) 단순 했습니다.

     

    요청 변수에 jobld와 jobGrowld가 존재 하였고

     

    유형칸과 설명칸이 존재했습니다.

     

     

    또한 필수여부에 y로 되어 있어서 필수적인 사항이라고 볼 수 있는데요

     

    단순히 주소만 복사 붙여넣기만 해 줄 경우

     

    유니티 엔진 자체에서 경고 표시를 나타내는것을 볼 수 있었습니다.

     

     

    알아 보니 주소는 완성된 주소는 아니였고

    보시면 요청사항에 적혀 있는 jobId와 jobGrowId가 <> 안에 들어가 있는것을 볼 수 있는데

     

    요청변수를 선언해 주고

     

    문자열 보간법을 이용하여 완성 시켜 주어야 한다고 합니다.

     

     jobId와 jobGrowId 값은 현재 빈 값으로 되어 있는데,

     

    아까 보았던

     

    의 값 입니다.

     

    한번 더 스크립트 상에서 테스트를 해 볼수도 있지만!!

     

     

    api 사이트에서 요청 으로도 확인을 할 수도 있었습니다.

     

    이전에 했던 거너의 레인저가 생각 나서

     

    거너의 jobId와 레인저의 jobGrowld를 변수에 넣어 주었습니다.

     

    이 후 실행을 해보면, 무수히 많은(?) 스킬 리스트 들을 볼 수 게 되었습니다.

     

    신기하기도 하고 재미 있습니다.

     

    UnityWebRequest 방식은 해 보았으니

     

    이제 www방식을 살펴 볼 차례인데요

     

    UnityWebRequest 으로 선언 해 주었던 부분을 WWW로 바꿔 주었고,

     

    다른 점이 있다면 WWW는 SendWebRequest를 사용하지 않고

     

    바로 괄호를 사용한다는 점 과

     

    WWW아래 

    밑줄 경고 표시와 함께 "WWW은(는) 사용되지 않습니다." 문구가 뜬다는 것 입니다.

     

    이렇게 되도 사용이 된다고는 하는데..

     

    Console 창에 동일한 text가 뜨긴 하지만

     

    UnityWebRequest 을 사용하는게 unity 에서도 권장 하고 있고

     

    좀 더 안정적이라고 합니다.

     

     

    굉장히 기본적인 것만 가지고 1차원 적인 기능 구현만 찾아 봤었는데요.

     

    공부 욕구가 마구 차오르고 있습니다.

     

    하루하루 한걸음식 좀 더 발전하는 형태로 찾아 오겠습니다.

     

    감사합니다.

     

     

     

     

    댓글

김효겸 / Tel. 010-7735-0580 / E-mail. dollzzang2@hanmail.net