API 개발 제4 편: 클 라 이언 트 / 서버 인터페이스 프로 토 콜 정의

API 개발 을 진행 할 때 app 과 server 가 상호작용 하 는 데이터 형식 을 미리 정의 해 야 전단 인원 과 서버 직원 들 이 데 이 터 를 어떻게 얻 고 데 이 터 를 어떻게 분석 하 며 프로 토 콜 을 어떻게 전송 하 는 지 미리 결정 할 수 있 습 니 다.내 가 보기에 현재 인터페이스 프로 토 콜 은 이 세 가지 상황 밖 에 없다. 1. json 데이터 가 상호작용 을 한다. 2. xml 데이터 가 상호작용 을 한다. 3. 사용자 정의 데이터 형식 상호작용
사용자 정의 데이터 형식 으로 앞 뒤 데이터 상호작용 을 하려 면 비교적 큰 정력 을 들 여야 하고 경험 이 있 는 사람 이 디자인 한 협의 가 있어 야 각 플랫폼 의 호환성 과 좋 은 읽 기 가능성 을 확보 할 수 있다.또한 분석, 포장 은 모두 스스로 코드 로 이 루어 져 야 하기 때문에 많은 제3자 라 이브 러 리 를 사용 할 수 없다.여기 서 나 는 토론 을 하지 않 기 때문이다.주로 json 과 xml 를 상호작용 데이터 로 한다.
나 는 나의 response 에 json 과 xml 를 봉 했다.클 라 이언 트 는 자신의 필요 에 따라 json 데 이 터 를 가 져 올 지 xml 를 가 져 올 지 선택 할 수 있 습 니 다.지정 방법 은 요청 한 url 에서 format = json / xml 를 지정 합 니 다.여기 서 프로그램의 건장 함 을 위해 저 는 기본적으로 데이터 형식의 반환 을 지정 합 니 다. 즉, 클 라 이언 트 가 format 설정 을 잊 거나 잊 어 버 리 면 기본 값 으로 json 데 이 터 를 되 돌려 줍 니 다.
json 데이터 의 봉인 은 php 에서 json 으로 데이터 상호작용 을 하 는 것 이 매우 편리 하 다.구현 코드:

    private static function jsonSucEncode($code, $msg, $datas){
        if(!is_numeric($code)){
            return '';
        }

        $ret = array(
                'succode'   => $code,
                'sucmsg'    => $msg,
                'datas'     => $datas,
        );

        echo json_encode($ret);
    }

코드 는 되 돌아 오 는 상태 코드 를 표시 합 니 다. 이 상태 코드 는 문서 에서 의 미 를 설명 하고 msg 가 되 돌아 오 는 정 보 를 미리 정의 해 야 합 니 다. 저 는 이 필드 가 필요 하 다 고 생각 합 니 다. 적어도 클 라 이언 트 개발 자 들 이 잘못된 포 지 셔 닝 을 하 는 데 편리 하 다 고 생각 합 니 다.비고: 저 는 처음에 이 필드 를 설계 하지 않 고 코드 라 는 상 태 를 설 계 했 습 니까? 전단 직원 들 은 매번 문서 에 가서 이 상태 코드 가 어떤 의미 인지 확인 하고 개발 속도 에 영향 을 주 었 습 니 다.datas: 이것 이 바로 전단 에 되 돌아 온 업무 데이터 입 니 다.그리고 제 이 슨encode () 가 이 데 이 터 를 인 코딩 한 후에 제 이 슨 데이터 입 니 다.xml 데이터 의 패 키 징 은 상대 적 으로 번 거 롭 고 방법 이 많 습 니 다. 저 는 문자열 로 연결 하 는 것 을 사용 합 니 다.

    private static function xmlSucEncode($code, $msg, $datas){
        if(!is_numeric($code)){
            return '';
        }

        $ret = array(
                'succode'   => $code,
                'sucmsg'    => $msg,
                'datas'     => $datas,
        );

        echo self::xml($ret);
    }
    private static function xml($datas){
        header("Content-Type:text/xml");

        $xml = "<?xml version='1.0' encoding='UTF-8'?>";

        $xml .= '<root>';
        $xml .= self::createXML($datas);
        $xml .= '</root>';

        return $xml;
    }
    private static function createXML($datas){
        $xml = $attr = "";

        foreach ($datas as $k=>$v){
            if(is_numeric($k)) {//   k   ，            
                $attr = " id='{$k}'";
                $k = "item";
            }

            $xml .= "<{$k}{$attr}>";
            $xml .= is_array($v) ? self::createXML($v) : $v;
            $xml .="</{$k}>";
        }

        return $xml;
    }

그 다음 에 현재 xml 데이터, json 데이터 의 패 키 징 방식 이 모두 있 습 니 다. 이때 통 일 된 인 터 페 이 스 를 제공 하여 프론트 데스크 에서 호출 할 수 있 도록 해 야 합 니 다. 매개 변 수 를 통 해 제어 하고 xml 데 이 터 를 되 돌려 야 합 니까? 아니면 json 데 이 터 를 되 돌려 야 합 니까?이렇게 두 개의 인 터 페 이 스 를 던 져 서 클 라 이언 트 가 스스로 선택 하도록 하 는 것 이 아니다.두 개의 인 터 페 이 스 를 던 지 는 동시에 또 하나의 문제 가 있다. 바 꾸 려 면 인터페이스의 이름과 그 인 자 를 바 꾸 는 것 이다.여기 서 내 가 정의 한 통 일 된 인터페이스:

    public static function sendEncode($code, $msg, $state, $datas=array(), $type=self::JSON){
        //              ，        ，          ，   json
        $type = isset($_GET['format']) ? $_GET['format'] : $type;

        switch ($type){
            // json    
            case self::JSON :
                if($state == self::SUCCESS){
                    self::jsonSucEncode($code, $msg, $datas);
                }else{
                    self::jsonErrEncode($code, $msg);
                }
                exit;
                break;
            // xml  
            case self::XML :
                if($state == self::SUCCESS){
                    self::xmlSucEncode($code, $msg, $datas);
                }else{
                    self::xmlErrEncode($code, $msg);
                }
                exit;
                break;
            //          
            default:
                self::jsonErrEncode(self::ILLEGAL_CODE, self::ILLEGAL_MSG);
                exit;
                break;
        }
    }

이 안에 상수 가 있 습 니 다. 저 는 response 라 는 종류 에 정의 되 어 있 습 니 다. 여 기 는 쓰 지 않 겠 습 니 다. 여러분 이 알 아 맞 힐 수 있 을 거 라 고 믿 습 니 다.만약 에 이 도구 의 완전한 실현 방식 을 필요 로 하 는 사람 이 있 으 면 메 일 을 남 겨 도 됩 니 다. 제 가 보 내 드 리 겠 습 니 다. 같이 공부 하고 발전 하 겠 습 니 다.다섯 번 째 편 은 제 가 인터페이스 디자인 에서 앱 에 이 부분 을 등록 한 실례 를 공유 하 겠 습 니 다.
app 백 엔 드 개발 시리즈 글 디 렉 터 리