728x90
이 글은 클라이언트 개발자가 작성하는 간단한 서버 지식과
postman을 돌리거나 개발을 할 때 도움을 주기 위해 포스팅한 글 입니다..
그래서 서버 개발자가 보기에는 제법 웃길 수 있습니다..~
1.
포스트맨이란?
Postman은 개발자가 API를 설계, 빌드, 테스트 및 반복할 수 있는 API 플랫폼
즉, 공유된 API를 테스트하고 서버통신 작업에 대한 실수를 방지해줍니다.
즉,클라이언트 개발자 입장에서, 서버 개발자가 넘겨준 api를 돌려보면서 status값을 확인하고 request값, response값을 확인하는 과정을 가진다!
2. Http Method
HTTP : HyperText Transfer Protocol 인터넷 상에서 클라이언트와 서버가 자원을 주고받을 때 사용하는 통신 규약
클라이언트와 서버가 네트워크를 통해 리소스를 주고받을 때 지켜야하는 통신 규약이 있습니다. 이를 HTTP라고 부릅니다. 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트가 요청(Request)를 보내면 서버가 응답(Response)하는 구조를 토대로 구성되어 있습니다.
HTTP Method는 크게 GET, POST, PUT, DELETE가 대표인데,
조회: GET
등록: POST
수정: PUT
삭제: DELETE
라고만 정리해서 알고있으면 될 거 같습니다!
그래서 위의 4개의 method를 가지고 CRUD를 구현할 수 있습니다.
그럼 이제 본격적으로 알아봅세다 ~
참고로 우리는 서버 개발자가 아니고 클라이언트 개발자인만큼 아주 상세한 내용은 다루지 않고,
우리가 필요한 최소한의 부분만 발췌해서 봅시다!
그리고 좀 더 깊게 들어가서 볼라고 해도 제가 모르기때문에 ~~
3.
Request Header
우리의 합동세미나 api를 보면 모두 공통적으로 아래의 사진과 같은 Request-Header가 들어가있는 것을 볼 수 있습니다
Request-Header란? 페치 될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
쉽게 말하면, 저희가 요청을 보낼 때, 해당 유저에 대해서 더 자세한 정보를 서버한테 보낼 수있다는 말로 이해하고 있습니다 (그래서 나중에 앱잼떄 가면 쓸 수도 있는 device token, refresh token, jwt token도 모두 request header로 넣어줬습니다) 그래서 여기서는 user에 대한 정보를 서버한테 보내기 위해 userId 또한 포함되어있다고 판단됩니다! (뭐 서버 설계상의 구조나 다른 부분에 있어서 또 관점이 다르겠지만.. just 저의 이해한 바 대로 적어보겠습니다..~)
Content-type
Content-Type이란 리소스의 미디어 타입을 나타내기 위해 사용된다. 요청(request)에서 Content-Type은 클라이언트가 서버에게 어떤 형식의 데이터가 실제로 보내지는 것인지 알려주는 용도로 사용됩니다.
request body
xml, json, mutli form 등등의 데이터를 담아서 서버한테 보내주는 역할을 합니다. 여기서는 글을 작성하는 api인 만큼 서버에게 작성자와 트윗 내용을 보내주고있죠 ?! (참고로 get같은 경우는 request body값을 가지지 않다는 점 기억해두기!)
그럼 이제 저 부분을 토대로 postman을 돌려보겠습니다
restful api에서는
프로토콜 + BaseURL + 자원을 식별하는 부분으로 나뉘어져있습니다
혹시모를 서버 개발자님의 저작권을 위해 BaseURL은 가리겠습니다~
우선, 서버에서 제공해준 api를 보면 method와 baseURL, 식별할 수 있는 경로 ("/twit")를 제공해줄 겁니다
그래서 그 부분을 세팅하고 만약 위와 같은 형식으로 api에 헤더가 있다면, "Headers"에서 key-value 형식으로 넣어주면 됩니다
다음으로는 아래와 같이 body값에 서버에게 보내줄 내용을 json 형식으로 작성한 후, send를 보내면 아래와 같은 응답이 돌아오는 것을 알 수 있습니다 (참고로 request, response 객체 설계법은 넘어가도록 하겠슴다 ~)
그리고 resposne 코드 같은 경우는 우측 중반에 status를 보고 확인할 수 있습니다.
- 2XX (성공) : 요청을 성공적으로 받았으며 인식했고 수용함
- 4XX(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
- 5XX(서버 오류): 서버가 명백해 유효한 요청에 대해 충족을 실패했음
원래 1XX,3XX도 있긴한데 제가 아직까지 본적이 없다보니 큰 필요성을 못느껴서.. 나중에 필요성을 느끼게 되면 추가로 작성하겠습니다
그럼 이제 가장 궁금하실 path와 param에 대해 알아보겠습니다
우선 비교를 해보기 위해 Github API를 가져와보겠습니다
(참고로 여기 부분 설명은 킹갓제너럴 '한승현'씨의 설명을 허락을 구한 뒤 일부 발췌했습니다)
왼쪽의 Path parameter와 Query parameter라고 적힌 부분을 보겠습니다.
Path parameter로 username을 보내달라고 합니다. Required라고 적힌걸 보니, 꼭 넘겨줘야 할 것 같습니다. 넘겨준 username에 해당하는 user의 팔로워 목록을 응답으로 주는 API이기 때문에 그렇습니다.
반면 Query parameter에는 per_page와 page를 넘겨달라고 합니다. 이는 Required가 적혀있지 않으므로 필수는 아닌 것 같다고 예측해볼 수 있습니다. per_page는 한 페이지에 결과를 몇 개나 담을지에 대한 값이고, page는 가져올 결과의 페이지 번호를 의미합니다. 만약 per_page를 100으로 설정하고 page를 3이라고 한다면, page 1에는 팔로워 1~100, page 2에는 팔로워 101~200, page 3에는 팔로워 201~300에 해당하므로 팔로워를 쭉 나열했을 때 201번 팔로워부터 300번 팔로워까지, 100명의 팔로워 정보에 해당하는 응답이 올 것입니다.
즉 위의 API는 /users/{username}/followers라는 하나의 end point로 요청을 보내되, Request Parameter의 값을 다르게 전달함으로써 하나의 end point에 다양한 응답을 기대할 수 있는 API가 되었습니다.
저는 서버 개발에는 관심이 없습니다. Path와 Query가 어떻게 다른지는 그닥 궁금하지 않습니다. 하지만 클라이언트 개발 업계에 몸담을 생각을 가진 사람이기 때문에, Path와 Query로 저렇게 나뉘어져 있으면 어떻게 클라이언트에서 API 연결을 구현할지 알아야 하는 것은 당연한 일입니다.
네네 뭔말인지 대충 이해하셨나요? 이제 다시 제 설명으로 돌아오겠습니다
쉽게 이야기하자면, 다음과 같습니다.
만약 어떤 resource를 식별하고 싶으면 Path Variable을 사용하고,
정렬이나 필터링을 한다면 Query Parameter를 사용하는 것이 Best Practice이다
그런데 사실 저희는 서버 개발자가 아니기때문에, 서버에서 뭔가 API를 주면 그거에 맞게 코드만 짜면 됩니다 (물론 저의 틀린 마음가짐일 수도 있지만 ^^)
여러분 혹시 이거만 보고 path인지 query인지 알 수 있나여?
정답은 path입니다!
보통 SOPT 서버 개발자들은 Path를 다음과 같이 표시해줍니다.
/:변수명 -또는- {변수명}
전자의 경우는 Postman이 저렇게 표시하곤 합니다. 반면 후자의 경우는 Android Retrofit이 저렇게 표시합니다.
다음은 포스트맨에서 조회를 해볼때와, 코드 짤때의 예시입니다.
Query같은 경우는 저는 거의 아래와 같은 형식으로 항상 api를 받았던 거 같습니다!
Query와 Path를 구분짓는 가장 쉬운 방법 중 하나는, 이 변수가 ? 뒤에 있는지를 확인하는 것입니다. 모든 Query 변수는 ? 뒤에 존재하며, Query가 여럿일 경우에는 ? 뒤에 &로 연결됩니다.
네 그럼 이제 살짝 사용법을 아시겠나요 ?
그렇담 저도 만족입니다 하하!
사실 저도 이번에 공부를 하게 되서 행복해요
그럼 마지막으로 하나 꿀팁을 드리자면...
저희 request body값은 그렇다치고, response body값을 옮길 때 많이 어려우시지 않으셨나요?
그런 과정에서 오류도 많이 발견되고..
그럴땐 Kotlin data class File from JSON을 강추드리겠습니다
다음 파일에 postman response값을 붙여넣고 클래스 이름을 설정한 뒤, generate 버튼을 누르면 바로 생성이 됩니다!
그러면 오류가 최소화되고 만드는데 시간도 굉장히 적게 걸리기때문에..~ 혼자서 data class 파일의 구조를 이해했다고 생각이 들 때 쯤에서 강추드리겠습니다..!
ㄱㅏㅁㅅㅏㅎㅏㅂㄴㅣㄷㅏ~
728x90
댓글