ย้ายข้อมูลจาก Geocoding v3 ไปยัง v4

Geocoding API v4 เปิดตัวเมธอดใหม่หลายรายการที่จะมาแทนที่ฟังก์ชันการทำงาน ใน API เวอร์ชัน 3 คู่มือนี้จะแสดงวิธีย้ายข้อมูลแอปเพื่อใช้เมธอด v4 ใหม่

คุณใช้คีย์ API ที่มีอยู่กับเมธอด v4 ใหม่ได้ อย่างไรก็ตาม หากคุณได้ขอเพิ่มโควต้าใน API เวอร์ชัน 3 คุณต้องขอเพิ่มโควต้าใน API เวอร์ชัน 4 ใหม่

ย้ายข้อมูลจากการเข้ารหัสที่อยู่เป็นพิกัดภูมิศาสตร์เวอร์ชัน 3

หากใช้ v3 Geocoding เพื่อ แปลงรหัสพิกัดภูมิศาสตร์ของที่อยู่ คุณควรย้ายข้อมูลไปยังเมธอด Geocode an address ใน v4 ซึ่งยอมรับคำขอ GET

API เวอร์ชัน 4 เปลี่ยนชื่อ โครงสร้าง และการรองรับพารามิเตอร์หลายรายการ เราขอแนะนำเป็นอย่างยิ่งให้คุณใช้ฟิลด์ มาสก์เพื่อระบุฟิลด์ที่คุณ ต้องการให้แสดงผลในการตอบกลับ

การเปลี่ยนแปลงพารามิเตอร์คำขอ

การเปลี่ยนแปลงช่องคำตอบ

สร้างตัวกรองคอมโพเนนต์ v3 ซ้ำ

Forward Geocoding ใน Geocoding v3 มีพารามิเตอร์ components ที่เปิดใช้การกรองผลลัพธ์อย่างเข้มงวดสำหรับคอมโพเนนต์ที่เฉพาะเจาะจง (เช่น components=country:US) Forward Geocoding ใน v4 ไม่รองรับการกรองอย่างเข้มงวดประเภทนี้ในพารามิเตอร์คำขอ ใน v4 คุณสามารถระบุข้อมูลที่อยู่ เป็นสตริงเดียวที่ไม่มีโครงสร้างในเส้นทาง หรือเป็นพารามิเตอร์การค้นหาที่มีโครงสร้าง เช่น address.addressLines, address.locality, address.administrativeArea, address.postalCode และ address.regionCode พารามิเตอร์ที่มีโครงสร้างไม่ได้ทําหน้าที่เป็นตัวกรองที่เข้มงวด แต่ระบบจะรวมคอมโพเนนต์ทั้งหมดที่ระบุเพื่อสร้างที่อยู่ที่สมบูรณ์ซึ่ง API จะพยายาม เข้ารหัสพิกัดภูมิศาสตร์ API จะค้นหาที่อยู่ทั้งหมดที่ระบุซึ่งตรงกันมากที่สุด ในทุกคอมโพเนนต์ การระบุคอมโพเนนต์ในลักษณะที่มีโครงสร้างจะช่วยให้ API เข้าใจเจตนาได้ดียิ่งขึ้น โดยเฉพาะอย่างยิ่งเมื่อรวบรวมข้อมูลที่อยู่จากช่องแบบฟอร์มแยกกัน ซึ่งจะช่วยให้ API จัดการการสะกดคำผิดเล็กๆ น้อยๆ หรือความคลุมเครือภายในแต่ละคอมโพเนนต์ได้ เนื่องจากประเภทข้อมูลในแต่ละฟิลด์ชัดเจน

หากต้องการให้ลักษณะการทำงานคล้ายกับตัวกรองคอมโพเนนต์แบบฮาร์ดของ v3 คุณต้องใช้ การกรองฝั่งไคลเอ็นต์ในอาร์เรย์ results ที่ API v4 ส่งคืนตามออบเจ็กต์ postalAddress และ addressComponents ในการตอบกลับ

ตารางต่อไปนี้แสดงการจับคู่ที่ดีที่สุดระหว่างตัวกรอง v3 components กับฟิลด์ v4 postalAddress

ตัวอย่างการกรองฝั่งไคลเอ็นต์

ตัวอย่างต่อไปนี้แสดงวิธีกรองผลลัพธ์เพื่อให้ได้ลักษณะการทำงานที่คล้ายกับการกรองคอมโพเนนต์ v3 สำหรับฟิลด์ที่รองรับ ได้แก่ ประเทศ เขตการปกครอง และรหัสไปรษณีย์ ไม่แนะนำให้ กรองในช่องอื่นๆ เนื่องจากไม่มีเกณฑ์การกรองที่เชื่อถือได้

กรองตามประเทศ

จับคู่ address.regionCode จากคำขอของคุณกับ postalAddress.regionCode ในผลลัพธ์แต่ละรายการ โปรดทราบว่าแม้ว่า API จะยอมรับรหัสภูมิภาคที่เป็นตัวพิมพ์เล็กในคำขอ แต่จะแสดงรหัสเหล่านั้นเป็นตัวพิมพ์ใหญ่ในการตอบกลับเสมอ ดังนั้นคุณต้องแปลงอินพุตเป็นตัวพิมพ์ใหญ่ก่อนเปรียบเทียบ

def filter_by_country(results, region_code):
    return [
        res for res in results
        if res.get('postalAddress', {}).get('regionCode') == region_code.upper()
    ]

# Example usage:
# v4_response = ... # API call response
# filtered = filter_by_country(v4_response.get('results', []), 'US')

function filterByCountry(results, regionCode) {
    return results.filter(res => res.postalAddress?.regionCode === regionCode.toUpperCase());
}

// Example usage:
// const v4Response = ... # API call response
// const filtered = filterByCountry(v4Response.results, 'US');

กรองตามเขตบริหาร

จับคู่ address.administrativeArea จากคำขอของคุณกับ postalAddress.administrativeArea ในผลลัพธ์แต่ละรายการ เช่นเดียวกับรหัสประเทศ คุณควรแปลงอินพุตเป็นตัวพิมพ์ใหญ่ก่อนเปรียบเทียบ ค่านี้จะเชื่อถือได้เฉพาะเมื่อ administrativeArea ในคำขอของคุณระบุด้วยตัวย่อ 2 ตัวอักษรมาตรฐาน postalAddress.administrativeArea ในการตอบกลับอาจไม่ตรงกับคำต่อท้ายรหัส ISO 3166-2 โดยตรงเนื่องจากสาเหตุหลายประการ ประการแรก ในบางพื้นที่ เขตปกครองย่อยที่สอดคล้องกับรหัส ISO 3166-2 ไม่ได้เป็นส่วนหนึ่งของการแสดงที่อยู่ไปรษณีย์มาตรฐาน ตัวอย่างเช่น ในสเปน ระดับพื้นที่การปกครอง 1 (เช่น "CN" สำหรับกานาเรียส) อาจอยู่ใน addressComponents แต่ postalAddress.administrativeArea อาจมีพื้นที่ระดับ 2 (เช่น "ซานตาครูซเดเตเนริเฟ") ประการที่สอง ในบางพื้นที่ ตัวย่อของเขตย่อย ไม่เป็นที่นิยมใช้และแสดงใน postalAddress.administrativeArea ด้วยชื่อที่ยาวขึ้น (ด้วยเหตุผลที่คล้ายกัน addressComponents.shortText สำหรับคอมโพเนนต์ที่อยู่ ที่สอดคล้องกับเขตย่อยอาจไม่ตรงกับคำต่อท้ายรหัส ISO 3166-2 ของเขตย่อย) นอกจากนี้ ในบางกรณี อาจมีการแสดงส่วนย่อยในคอมโพเนนต์ที่อยู่สำหรับ administrative_area_level_n ที่มี n มากกว่า 1 เพื่อให้ได้ผลลัพธ์ที่ครอบคลุมมากที่สุด คุณควรตรวจสอบการจับคู่ในทั้ง postalAddress.administrativeArea และ addressComponents ที่มีประเภท administrative_area_level_n (เช่น administrative_area_level_1)

def filter_by_admin_area(results, admin_area):
    target = admin_area.upper()
    filtered = []
    for res in results:
        # Check postalAddress
        pa_aa = res.get('postalAddress', {}).get('administrativeArea', '')
        if pa_aa == target:
            filtered.append(res)
            continue
        # Check all administrative area levels in addressComponents
        for comp in res.get('addressComponents', []):
            is_admin_level = any(t.startswith('administrative_area_level_')
                               for t in comp.get('types', []))
            if is_admin_level:
                short = comp.get('shortText', '')
                if short == target:
                    filtered.append(res)
                    break
    return filtered

# Example usage:
# filtered = filter_by_admin_area(v4_response.get('results', []), 'CA')

function filterByAdminArea(results, adminArea) {
    const target = adminArea.toUpperCase();
    return results.filter(res => {
        // Check postalAddress.administrativeArea
        if (res.postalAddress?.administrativeArea === target) {
            return true;
        }
        // Check addressComponents for any administrative area level
        return res.addressComponents?.some(c => {
            const isAdmin = c.types?.some(t => t.startsWith('administrative_area_level_'));
            return isAdmin && c.shortText === target;
        });
    });
}

// Example usage:
// const filtered = filterByAdminArea(v4Response.results, 'CA');

กรองตามรหัสไปรษณีย์

จับคู่ address.postalCode จากคำขอของคุณกับ postalAddress.postalCode ในผลลัพธ์แต่ละรายการ คุณต้องแปลงรหัสไปรษณีย์ทั้งอินพุตและผลลัพธ์เป็นรูปแบบมาตรฐานก่อนเปรียบเทียบ ตรรกะการปรับให้เป็นมาตรฐานขึ้นอยู่กับภูมิภาคเป็นอย่างมาก แนวทางพื้นฐานคือการนำช่องว่างและขีดกลางออก แล้วแปลงเป็นตัวพิมพ์เล็กหรือตัวพิมพ์ใหญ่ให้สอดคล้องกัน

อาจต้องมีการจัดรูปแบบขั้นสูงเพิ่มเติมเพื่อจัดการคำนำหน้ารหัสไปรษณีย์ (เช่น "L2" ในสหราชอาณาจักร) หรือคำต่อท้าย (เช่น "+4" ในรหัสไปรษณีย์ของสหรัฐอเมริกา) ตรรกะการแปลงรูปแบบเฉพาะที่จำเป็นจะแตกต่างกันไปตามประเทศและรูปแบบของรหัสไปรษณีย์ที่เกี่ยวข้อง คุณอาจต้องปรับฟังก์ชันการทำให้เป็นมาตรฐานที่ให้ไว้ หรือใช้ตรรกะที่ซับซ้อนมากขึ้นสำหรับภูมิภาคที่คุณกำหนดเป้าหมาย

แฮชตัวอย่างที่ระบุจะจัดการรหัสไปรษณีย์ของสหรัฐอเมริกาและอนุญาตให้จับคู่กับฐาน 5 หลักได้แม้ว่าจะมีการระบุหรือส่งคืนรหัสไปรษณีย์ที่มีรหัสเพิ่มเติม 4 หลักก็ตาม

import re

def normalize_postal_code_us(pc):
    # Basic normalization for US: uppercase, alphanumeric only
    if not pc:
        return ""
    normalized = re.sub(r'[^A-Z0-9]', '', pc.upper())
    # Return only the first 5 digits for US ZIP codes
    return normalized[:5]

def filter_by_postal_code_us(results, postal_code):
    normalized_input = normalize_postal_code_us(postal_code)
    if not normalized_input:
        return []
    filtered_results = []
    for res in results:
        pa_pc = res.get('postalAddress', {}).get('postalCode', '')
        if normalize_postal_code_us(pa_pc) == normalized_input:
            filtered_results.append(res)
    return filtered_results

# Example usage:
# Matches '94043', '94043-1351', '940431351'
# filtered = filter_by_postal_code_us(v4_response.get('results', []), '94043')
# filtered = filter_by_postal_code_us(v4_response.get('results', []), '94043-1234')

function normalizePostalCodeUs(pc) {
    // Basic normalization for US: uppercase, alphanumeric only
    const normalized = (pc || '').toUpperCase().replace(/[^A-Z0-9]/g, '');
    // Return only the first 5 digits for US ZIP codes
    return normalized.substring(0, 5);
}

function filterByPostalCodeUs(results, postalCode) {
    const normalizedInput = normalizePostalCodeUs(postalCode);
    if (!normalizedInput) {
        return [];
    }
    return results.filter(res => {
        const paPc = res.postalAddress?.postalCode || '';
        return normalizePostalCodeUs(paPc) === normalizedInput;
    });
}

// Example usage:
// Matches '94043', '94043-1351', '940431351'
// const filtered = filterByPostalCodeUs(v4Response.results, '94043');
// const filtered = filterByPostalCodeUs(v4Response.results, '94043-1234');

ย้ายข้อมูลจากการเข้ารหัสพิกัดภูมิศาสตร์แบบย้อนกลับ v3

หากใช้ Reverse Geocoding v3 เพื่อเปลี่ยนพิกัดเป็นที่อยู่ คุณควรย้ายข้อมูลไปยังเมธอด Reverse Geocode ตำแหน่ง v4 ซึ่งยอมรับคำขอ GET

API เวอร์ชัน 4 เปลี่ยนชื่อ โครงสร้าง และการรองรับพารามิเตอร์หลายรายการ เราขอแนะนำเป็นอย่างยิ่งให้คุณใช้ฟิลด์ มาสก์เพื่อระบุฟิลด์ที่คุณ ต้องการให้แสดงผลในการตอบกลับ

การเปลี่ยนแปลงพารามิเตอร์คำขอ

การเปลี่ยนแปลงช่องคำตอบ

ย้ายข้อมูลจากตัวอธิบายที่อยู่ v3

หากใช้ address_descriptor เพื่อรับข้อมูลเพิ่มเติมเกี่ยวกับสถานที่ตั้งด้วย Geocoding v3 คุณต้องย้ายข้อมูลไปใช้ฟิลด์ landmarks ของ SearchDestinationsResponse

ย้ายข้อมูลจากการเข้ารหัสพิกัดภูมิศาสตร์ของสถานที่ v3

หากใช้ place_id เพื่อรับที่อยู่สำหรับรหัสสถานที่ที่เฉพาะเจาะจงด้วย Geocoding v3 คุณต้องย้ายข้อมูลไปยังเมธอด Place Geocoding v4 ซึ่ง ยอมรับคำขอ GET

API เวอร์ชัน 4 เปลี่ยนชื่อ โครงสร้าง และการรองรับพารามิเตอร์หลายรายการ เราขอแนะนำเป็นอย่างยิ่งให้คุณใช้ฟิลด์ มาสก์เพื่อระบุฟิลด์ที่คุณ ต้องการให้แสดงผลในการตอบกลับ

การเปลี่ยนแปลงพารามิเตอร์คำขอ

การเปลี่ยนแปลงช่องคำตอบ

ย้ายข้อมูลจากข้อมูลไฮเปอร์โลคัลของการเข้ารหัสพิกัดภูมิศาสตร์ไปยังปลายทาง

ฟีเจอร์ต่อไปนี้ใน Geocoding API v3 จะถูกแทนที่ด้วยเมธอด SearchDestinations ของ Geocoding API v4

• การเข้าชม
• จุดนำทาง
• โครงร่างของอาคาร
• ค่าเข้า

หากคุณใช้ Geocoding API v3 สำหรับฟีเจอร์ข้างต้น โปรดใช้เอกสารนี้ เพื่อช่วยให้คุณใช้เมธอด SearchDestinations แทนเพื่อรับฟีเจอร์เหล่านี้ เอกสารนี้อธิบายตำแหน่งในSearchDestinationsการตอบกลับเพื่อค้นหาฟีเจอร์เหล่านี้ และความแตกต่างของวิธีแสดงฟีเจอร์เหล่านี้ในการตอบกลับ API ระหว่าง Geocoding API v3 กับเมธอด SearchDestinations ของ Geocoding API v4

การเข้าชม

หากต้องการรับทางเข้าที่เชื่อมโยงกับ destination ให้ใช้ฟิลด์ destination.entrances

โปรดทราบว่ารูปแบบของ entrance จะแตกต่างจากรูปแบบทางเข้าใน Geocoding API v3 เล็กน้อย ทางเข้าแต่ละแห่ง ใน destination.entrances มีฟิลด์ต่อไปนี้

• displayName - นี่คือฟิลด์ใหม่ที่ไม่บังคับซึ่งจะมีชื่อที่มนุษย์อ่านได้ สำหรับทางเข้า เช่น "ประตู B"
• location - นี่คือสถานที่ตั้งประเภท LatLng ซึ่งแตกต่างจากรูปแบบที่ใช้ใน Geocoding API v3
• tags - เหมือนกับฟิลด์ tags ของทางเข้าจาก Geocoding API v3
• place - เทียบเท่ากับฟิลด์ buildingPlaceId ของทางเข้าจาก Geocoding API v3 อย่างไรก็ตาม รหัสสถานที่ในฟิลด์นี้อาจเป็นรหัสสถานที่ประเภทใดก็ได้ ไม่จำเป็นต้องเป็นอาคารเท่านั้น

จุดนำทาง

หากต้องการรับจุดนำทางที่เชื่อมโยงกับ destination ให้ใช้ฟิลด์ destination.navigationPoints

โปรดทราบว่ารูปแบบของ navigationPoint จะแตกต่างจากรูปแบบจุดนำทางใน Geocoding API v3 เล็กน้อย จุดนำทางแต่ละจุดใน destination.navigationPoints มีฟิลด์ต่อไปนี้

• displayName - นี่คือฟิลด์ใหม่ที่ไม่บังคับซึ่งจะมีชื่อที่มนุษย์อ่านได้ สำหรับจุดนำทาง เช่น "5th Ave"
• location - นี่คือสถานที่ตั้งประเภท LatLng ซึ่งแตกต่างจากรูปแบบที่ใช้ใน Geocoding API v3
• travelModes - คล้ายกับฟิลด์ restrictedTravelModes ของ จุดนำทางจาก Geocoding API v3 ค่า Enum ที่เป็นไปได้จะเหมือนกัน ความแตกต่างเพียงอย่างเดียวคือตอนนี้ฟิลด์นี้แสดงถึงโหมดการเดินทางที่ยอมรับได้สำหรับจุดนำทาง แทนที่จะเป็นโหมดการเดินทางที่ถูกจำกัด
• usage - นี่คือฟิลด์ใหม่ที่มีกรณีการใช้งานที่จุดนำทางรองรับ โปรดทราบว่าจุดนำทางส่วนใหญ่จะมีUNKNOWNการใช้งาน แต่ไม่ได้หมายความว่าการใช้งานจุดนำทางจะถูก จำกัดในทางใดทางหนึ่ง

โครงร่างของอาคาร

หากต้องการรับโครงร่างอาคารที่เชื่อมโยงกับ destination คุณควรใช้ฟิลด์ displayPolygon ของออบเจ็กต์ placeView ใน destination ที่แสดงถึงอาคาร สำหรับแต่ละ placeView คุณ สามารถตรวจสอบว่าเป็นอาคารหรือไม่ด้วยฟิลด์ placeView.structureType หากประเภทโครงสร้างเป็น BUILDING คุณจะดูโครงร่างได้จากฟิลด์ placeView.displayPolygon placeView จะมีฟิลด์เพิ่มเติมสำหรับอาคารที่ไม่ได้อยู่ใน Geocoding API v3 ด้วย

destination อาจมีออบเจ็กต์ placeView ที่แสดงอาคารในฟิลด์ต่อไปนี้

• destination.primary - นี่คือสถานที่หลักของปลายทาง
• destination.containingPlaces - นี่คือฟิลด์ที่ซ้ำได้ซึ่งสามารถเก็บ สถานที่ขนาดใหญ่กว่าที่ "มี" สถานที่หลัก เช่น หากสถานที่หลักคือ subpremise โดยปกติแล้ว containingPlaces จะมี placeView ซึ่งแสดงถึงอาคาร
• destination.subDestinations - นี่คือฟิลด์ที่ซ้ำได้ซึ่งมี ปลายทางย่อยของสถานที่หลัก เช่น ห้องชุดแต่ละห้องในอาคาร โดยปกติแล้วฟิลด์นี้จะไม่มี placeView ซึ่งแสดงถึงอาคาร

โปรดทราบว่ารูปแบบของ placeView.displayPolygon ตรงกับรูปแบบโครงร่างอาคาร ใน Geocoding API v3 ซึ่งเป็นรูปแบบ GeoJSON โดยใช้รูปแบบ RFC 7946

ค่าเข้า

เช่นเดียวกับการสร้างขอบเขตอาคาร หากต้องการรับพื้นที่ที่เชื่อมโยงกับ destination คุณควรใช้ฟิลด์ displayPolygon ของออบเจ็กต์ placeView ใน destination ที่แสดงถึงพื้นที่ สำหรับแต่ละ placeView คุณ สามารถตรวจสอบว่ามีเหตุผลด้วยฟิลด์ placeView.structureType หรือไม่ หากประเภทโครงสร้างเป็น GROUNDS คุณจะดูโครงร่างได้จากฟิลด์ placeView.displayPolygon placeView จะมีฟิลด์เพิ่มเติมสำหรับเหตุผลที่ไม่ได้อยู่ใน Geocoding API v3 ด้วย

destination สามารถมีออบเจ็กต์ placeView ที่แสดงถึงเหตุผลในฟิลด์ต่อไปนี้

• destination.primary
• destination.containingPlaces
• destination.subDestinations

โปรดทราบว่ารูปแบบของ placeView.displayPolygon ตรงกับรูปแบบโครงร่างของพื้นที่ ใน Geocoding API v3 ซึ่งเป็นรูปแบบ GeoJSON ที่ใช้รูปแบบ RFC 7946

ความแม่นยำของผลลัพธ์

ใน Geocoding API v3 ฟิลด์ location_type ในเรขาคณิตการตอบกลับ ระบุความแม่นยำของผลลัพธ์ และไคลเอ็นต์บางรายจะจัดอันดับหรือกรอง ผลลัพธ์ตามค่าเหล่านี้ (ROOFTOP, RANGE_INTERPOLATED, GEOMETRIC_CENTER และ APPROXIMATE) ในการย้ายข้อมูล Geocoding API v4 มาตรฐาน ฟิลด์นี้จะเปลี่ยนชื่อเป็น granularity

ใน Destinations API (v4 SearchDestinations) ไม่มีฟิลด์ location_type แต่ระบบจะจัดการข้อมูลเชิงพื้นที่แตกต่างออกไป ดังนี้

• ไม่จำเป็นต้องกรองฝั่งไคลเอ็นต์ด้วยตนเอง: แม้ว่า Geocoding มาตรฐาน จะให้ผลลัพธ์หลายรายการในระดับความละเอียดต่างๆ แต่ SearchDestinationsจะลดความคลุมเครือโดยการแปลงเป็นปลายทางเดียว ที่ได้รับการเพิ่มประสิทธิภาพทุกครั้งที่เป็นไปได้ ซึ่งจะช่วยให้ลูกค้าไม่ต้องกรองตามประเภทสถานที่ตั้งเพื่อพิจารณาว่าผลลัพธ์ใดดีที่สุด
• ข้อมูลเชิงพื้นที่ที่แสดงโดยประเภทโครงสร้างและรูปหลายเหลี่ยมที่แสดง เรขาคณิตและโครงสร้างเชิงพื้นที่จะระบุโดย:
  • displayPolygon (สำหรับเรขาคณิตที่แน่นอน)
  • ฟิลด์ structureType ภายในออบเจ็กต์ placeView
• การแมปประเภทโครงสร้าง
  • structureType ของ POINT, BUILDING หรือ SECTION โดยทั่วไป จะสอดคล้องกับสิ่งที่เคยเรียกว่า ROOFTOP
  • structureType ของ GROUNDS โดยทั่วไปจะสอดคล้องกับ GEOMETRIC_CENTER

ใช้มาสก์ฟิลด์เพื่อขอฟีเจอร์เหล่านี้

เมธอด SearchDestinations ต้องใช้มาสก์ฟิลด์ตามที่อธิบายไว้ในเลือกฟิลด์ที่จะ แสดงผล คุณตั้งค่า FieldMask เป็น * เพื่อแสดงช่องทั้งหมด หรือตั้งค่าเป็นช่องที่เฉพาะเจาะจง ที่คุณต้องการรับก็ได้ ตัวอย่างเช่น คำขอ API ต่อไปนี้จะตั้งค่ามาสก์ฟิลด์ เพื่อรับฟิลด์ทั้งหมดที่จำเป็นในการรับทางเข้า จุดนำทาง โครงร่างอาคาร และพื้นของจุดหมาย

curl -X POST -d '{"place": "places/ChIJG3kh4hq6j4AR_XuFQnV0_t8"}' \
  -H "X-Goog-Api-Key: API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Goog-FieldMask: destinations.entrances,destinations.navigationPoints,destinations.primary,destinations.containingPlaces,destinations.subDestinations" \
  https://geocode.googleapis.com/v4/geocode/destinations

ข้อควรพิจารณาด้านความปลอดภัย

Geocoding API v4 ออกแบบมาให้เป็น API แบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ ไม่มีเส้นทางการย้ายข้อมูลโดยตรงจาก v3 ไปยัง v4 สำหรับผู้ใช้ JavaScript การเรียกใช้เมธอด v4 จาก JavaScript ฝั่งไคลเอ็นต์ (เช่น ในเบราว์เซอร์) โดยตรงโดยใช้คีย์ API จะทำให้คีย์ API ของคุณมีความเสี่ยงสูงต่อการถูกขโมยและการนำไปใช้ในทางที่ผิด

แม้ว่าการจำกัดผู้แนะนำ HTTP จะมีประโยชน์ แต่ก็ไม่เพียงพอที่จะป้องกันปลายทางของเว็บเซอร์วิส เนื่องจากผู้โจมตีสามารถข้ามการจำกัดนี้ได้อย่างง่ายดายโดยการปลอมแปลงส่วนหัว Referer ในคำขอ

แนวทางที่แนะนำ

วิธีที่แนะนําในการใช้ Geocoding API v4 คือจากเซิร์ฟเวอร์แบ็กเอนด์ของคุณเอง แอปพลิเคชันไคลเอ็นต์ควรส่งคำขอไปยังเซิร์ฟเวอร์ตัวกลางนี้ ซึ่งจะเรียกใช้ Google API อย่างปลอดภัยโดยใช้คีย์ API ที่ได้รับการปกป้อง (เช่น คีย์ที่จัดเก็บไว้ในตัวแปรสภาพแวดล้อมหรือ Secret Manager) ซึ่งจะช่วยให้มั่นใจได้ว่า คีย์ API จะไม่แสดงในโค้ดส่วนหน้า

ทางเลือกสำหรับความต้องการฝั่งไคลเอ็นต์

หากคุณมีความต้องการฝั่งไคลเอ็นต์ที่ต้องใช้ Geocoding ให้พิจารณาใช้โซลูชันฝั่งไคลเอ็นต์ที่มีอยู่ต่อไปนี้

• บริการการเข้ารหัสพิกัดภูมิศาสตร์ใน Maps JavaScript API: บริการการเข้ารหัสพิกัดภูมิศาสตร์จะยังคงใช้แบ็กเอนด์ v3 และออกแบบมาเพื่อใช้ในสภาพแวดล้อมของเบราว์เซอร์
• Places UI Kit: ใช้ Places UI Kit ซึ่งรวมถึงองค์ประกอบการเติมข้อความอัตโนมัติของสถานที่ สำหรับองค์ประกอบอินเทอร์เฟซผู้ใช้ที่เกี่ยวข้องกับที่อยู่