요청/응답 데이타 구조를 결정해야 합니다. > RESTful

RESTful

요청/응답 데이타 구조를 결정해야 합니다. 정보

요청/응답 데이타 구조를 결정해야 합니다.

본문

안녕하세요. 솔그누입니다.

 

이제 사용할 오픈소스는 결정이 끝났습니다. 테스트코드를 만들어 돌려보니 잘 동작합니다.

본격적으로 api 를 만들기 전에 결정해야 할것이 남았습니다.

 

1. api endpoint 

 ==> 이미 여러분께서 정리해두신게 있습니다. 참조하겠습니다.

 ==> 네이밍을 잘 할려고 하면, 머리가 아픕니다. 적당하게 만듭니다.(네이밍 보다는 문서화가 중요합니다.)

 

1-1. HTTP Method 를 정해야 합니다. 

==> GET/POST 이외에 PATCH/DELETE 도 활용하는게 좋겠지만, 웹서버에서 지원안하는 경우가 많습니다.

       그냥 GET / POST만 사용하고, api endpoint에 create/update/delete 를 명시합니다.  

       POST /member/{mb_id}/update

       POST /member/{mb_id}/delete

 

2. request / response data

==> 응답은 JSON 입니다. 다른걸 쓸필요가 없습니다. 고민하지 말고 그냥 JSON 입니다.

       요청은 form-urlencoded 또는 JSON 형태입니다. 이미지 업로드시에는 multipart 도 사용되게 됩니다.

       저는 form-urlencoded 를 선호합니다. 터미널에서 직접 테스트하는 경우가 많은데(curl, httpie) 중괄호와 쌍따옴표 타이핑이 은근히 귀찮습니다.

 

3. 요청 데이타는   form-urlencoded 로 결정했다면, 이제 응답 JSON 데이타를 정해야 합니다. 

==> 사용자에 따라 각자의 형태가 됩니다. 가급적 심플한 구조가 문서화 하기에 편리합니다.(설계보다 문서화가 중요합니다.)

 

3-1. http status 값을 어떤식으로 노출할지 정해야 합니다.

==> restful 문서 가이드를 보면 상태값을 주로 http status 값을 사용합니다.

       200 (OK), 404(Not Found), 400(Bad Request), 403, 500, etc...

      저는 이걸 응답 메세지에 코드화 시키는걸 선호합니다.

      api의http status 는 모두 200 으로 통일합니다. (진짜 서버 오류 나는 경우도 있으니..)   

 

4. 그래서 나온 최종 응답 데이타 구조입니다.

    {

      "status" : 200,

      "message" => "OK",

      "data" => {...}

    }

   - 응답이 정상이면 200 이고, message는 대부분 OK 입니다.

   - message 는 200인 경우 OK, 그외 상태인 경우 오류 메세지가 들어갑니다.

   - data 는 여러가지 형태의 응답 데이타를 포함하고 있습니다. body라는 명칭도 많이 쓰는데,

     http response body 랑 헷갈리는것 같아서 저는 data라는 변수를 씁니다.

   - 게시판 목록에 대한 응답이라면, data 는 대략 이렇게 구성됩니다.

  {

      "status" : 200,

      "message" => "OK",

      "data" => {

              "total" => 1020,

              "page" => 3,

              "filter" => {

                    "stx" => "...",

                    "sfl" => "....",

              },

              "order" => {

                  "sst" => "wr_id",

                 "ssd" => "desc",

             }

             "rows" => [

                     {

                       "bo_table" => "free",

                        "wr_id" => 1, 

                        "wr_subject" => "xxxxxxx",

                        .....

                      }

                     ......

              ]

        }

    }

 

 

 

추천
0

댓글 7개

응답 문서가 제일 중요할 것 같습니다.  이것이 같아야, 프런트엔드단 프로그램이 어느정도 호환성이 유지가 되지 않을까요?

요청하는쪽은  수정을 하더라도 조금일 것 같은데,  응답포맷이 다르면,  전체를 다 뜯어 고쳐야 될것 같습니다.

그래서 가능하면 응답 포맷을 문서화해서 일치 하면 좋을 것 같습니다.
어떡하다 보니 님 그리고 님 (닉네임은 솔그루인데 인사는 솔그누  어느게 맞나요?) 모두 REST관련 백엔드쪽만 하고 계시네요.  아마 두분의 실력은 프런트엔드까지도 직접하실 것 같긴한데,  그래도,  프런트엔드쪽 하시던 분 몇분이 앱개발 소모임에서 피드백을 주면 더 좋은 제품이 될 것 같습니다. 

즉 한사람이 앞뒤로 다하면,  가끔 산으로 올라갈 수도 있기 때문에,  프런트엔드만 하시는 분의 이야기도 들어 봤으면 좋을 것 같다는 생각입니다.
대부분의 API형태가 스테이터스, 메시지는 기본으로 보내고 data라는 값에 형태를 가지고 있습니다.
물론 코딩하는 사람 마음이지만
굳이 독자적 규격을 가져봐야 크게 의미가 없기도 하고요 다만 data안에서 보여주는 데이터의 경우 지금 예시로 드는것은 굳이 필요 없는 데이터도 있는것 같습니다
이부분이야 정리하면 될것 같구요.
검색을 해봐야 되지만, 궁금한것이.. 스테이터스와 메시지는 Response 헤더에 포함되어 오는 것으로 알고 있는데, JSON안에 넣어주면 편한가요?
동의합니다. 프론트랑 작업하다보면 요청 데이타를 다시  보내달라고 하는 경우가 많더라구요. 상태관리가 어렵거나 귀찮을수도 있겠지만.... 요청하니 만들어서 보내게 됩니다. 필요한만큼 가져다 쓰지 않을까요?
vue는 어설프게 한게 있다보니
이번에는 먼저 리액트쪽으로 프론트앤드도 개발하면서 같이 하려고 하고 있습니다.
어느정도 핵심적인 기능은 완성되었고 페이지 뷰를 보여주는데는 지금 구조로도 크게 문제가 없어서요.
전체 96 |RSS
RESTful 내용 검색

회원로그인

진행중 포인트경매

  1. 참여87 회 시작24.04.12 12:32 종료24.04.19 12:32
  2. 참여50 회 시작24.04.12 12:32 종료24.04.19 12:32
(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT