Demo langsung

Panduan

Apakah integrasi API, dijelaskan untuk perniagaan pelancongan

Integrasi API ialah sambungan yang membolehkan dua sistem perisian bertukar data dan mencetuskan tindakan tanpa sesiapa menaip semula apa-apa. Panduan ini menerangkan cara ia berfungsi melalui satu tempahan hotel yang bergerak antara pelancong, platform tempahan, API pembekal dan gerbang pembayaran.

  • Satu permintaan, satu respons
  • REST, XML, SOAP dan webhook
  • Satu tempahan dijejak merentas empat sistem
  • Cara integrasi diuji

Definisi

Apakah integrasi API, dalam bahasa mudah

API bermaksud application programming interface: set peraturan yang diterbitkan oleh sesuatu sistem supaya perisian lain boleh berkomunikasi dengannya. Integrasi API ialah kerja menyambungkan platform anda kepada salah satu antara muka itu supaya data bergerak dan tindakan berlaku secara automatik.

Dalam pelancongan, platform itu biasanya sistem tempahan seperti Perisian tempahan perjalanan, dan antara muka itu milik pembekal, gerbang pembayaran atau alat perniagaan. Halaman Integrasi API pelancongan kami menerangkan cara PHPTRAVELS menyampaikan sambungan ini, dan Semua integrasi menyenaraikan pembekal yang sudah disambungkan.

  • Bertukar data

    Kadar, ketersediaan, butiran pelanggan dan kemas kini status bergerak antara sistem dalam format berstruktur.

  • Mengautomasikan tindakan

    Cari, tempah, bayar, batal dan menyelaras berlaku sebagai permintaan, bukan langkah yang diulang seseorang secara manual.

  • Menjejak hasil

    Setiap panggilan membawa rujukan, jadi tempahan yang gagal boleh dijejak kembali kepada permintaan yang menyebabkannya.

Permintaan

POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{  "city": "DXB",  "check_in": "2026-11-12",  "check_out": "2026-11-14",  "guests": 2,  "currency": "USD"}

Respons

HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{  "hotel": "Palm Marina Hotel",  "room": "Deluxe, 2 adults",  "rate": { "amount": 438.00, "currency": "USD" },  "refundable": true,  "rate_key": "rk_19d2c7"}
Contoh panggilan kepada pembekal hotel rekaan. Nama medan, titik akhir dan jumlah berbeza antara satu pembekal dengan yang lain.

Anatomi satu panggilan API

  1. 1

    Titik akhir dan kaedah

    Alamat operasi dan kata kerja yang digunakan padanya: POST ke availability bermaksud mencari bilik.

  2. 2

    Pengesahan

    Kunci, token atau tandatangan membuktikan siapa yang memanggil. Pembekal mengeluarkan kelayakan berasingan untuk sandbox dan pengeluaran.

  3. 3

    Payload

    Input berstruktur: bandar, tarikh, tetamu dan mata wang. Dokumentasi pembekal mentakrifkan setiap medan.

  4. 4

    Kod status

    Nombor yang menyatakan bagaimana panggilan itu berjalan: 200 berjaya, 4xx masalah pada permintaan, 5xx masalah di pihak pembekal.

  5. 5

    ID permintaan

    Pengecam yang disimpan oleh kedua-dua pihak. Apabila sokongan bertanya apa yang berlaku pada sesuatu tempahan, inilah yang mereka cari.

  6. 6

    Badan respons

    Jawapan dalam format pembekal, yang dipetakan oleh platform anda kepada bilik, kadar dan polisinya sendiri.

Satu tempahan, empat sistem

Apa yang dilakukan integrasi API semasa tempahan hotel

Ikuti satu penginapan dua malam dari carian hingga baucar. Setiap anak panah ialah panggilan API; pelancong hanya melihat yang pertama dan yang terakhir.

  1. 01PelancongPlatform tempahanMencari hotel di Dubai, dua malam, dua tetamu
  2. 02Platform tempahanAPI pembekalPermintaan ketersediaan dengan tarikh, tetamu dan mata wang
  3. 03API pembekalPlatform tempahanBilik, kadar, polisi dan kunci kadar
  4. 04Platform tempahanPelancongKeputusan dipaparkan dengan markup dan mata wang anda
  5. 05Platform tempahanAPI pembekalSemakan semula harga pada kunci kadar yang dipilih sebelum pembayaran
  6. 06Platform tempahanGerbang pembayaranKebenaran pembayaran untuk jumlah keseluruhan
  7. 07Gerbang pembayaranPlatform tempahanDibenarkan, webhook bertandatangan diterima
  8. 08Platform tempahanAPI pembekalPermintaan tempahan dengan butiran tetamu
  9. 09API pembekalPlatform tempahanNombor pengesahan dan syarat pembatalan
  10. 10Platform tempahanPelancongBaucar, invois dan rujukan tempahan

Platform di tengah ialah tempat integrasi API wujud: ia menterjemah antara skrin pelancong dan format setiap pembekal, dan ia menyimpan setiap rujukan.

Urutan yang sama berfungsi untuk Perisian tempahan penerbangan dengan GDS, Perisian pengendali pelancongan dengan pembekal aktiviti dan Integrasi gerbang pembayaran dengan mana-mana gerbang; hanya nama medan yang berubah.

Gaya integrasi

REST, XML, SOAP, webhook dan GraphQL

Pembekal menerbitkan antara muka mereka dalam gaya berbeza. Gaya ditentukan oleh dokumentasi pembekal, bukan pilihan, jadi platform pelancongan perlu menyokong kesemuanya.

  • REST dan JSON

    JSON
    Format data
    Dokumen JSON
    Pengangkutan
    Kaedah HTTP: GET, POST, PUT, DELETE
    Lazim dalam pelancongan
    API penerbangan, hotel, aktiviti dan pembayaran yang lebih baharu
    Kekuatan
    Payload padat dan alatan pembangun yang meluas
    Perlu diawasi
    Spesifikasi longgar; setiap pembekal mentafsir REST secara berbeza

  • XML dan SOAP

    XML
    Format data
    Dokumen XML, selalunya dengan skema yang ketat
    Pengangkutan
    HTTP POST dengan sampul SOAP atau XML biasa
    Lazim dalam pelancongan
    GDS, bedbank dan sistem hotel serta pelancongan yang mapan
    Kekuatan
    Kontrak formal, tandatangan dan definisi perkhidmatan
    Perlu diawasi
    Mesej yang panjang dan penghuraian yang lebih berat

  • Webhook

    EVENT
    Format data
    JSON atau XML, ditolak oleh pihak satu lagi
    Pengangkutan
    HTTP POST ke URL yang anda daftarkan
    Lazim dalam pelancongan
    Keputusan pembayaran, perubahan status tempahan, kemas kini pengeluaran tiket
    Kekuatan
    Tiada polling; platform anda dimaklumkan apabila sesuatu berlaku
    Perlu diawasi
    Tandatangan mesti disahkan dan ulangan dikendalikan

  • GraphQL

    QUERY
    Format data
    JSON, dibentuk oleh pertanyaan yang anda hantar
    Pengangkutan
    Satu titik akhir HTTP tunggal
    Lazim dalam pelancongan
    Sesetengah platform pengedaran baharu dan API dalaman
    Kekuatan
    Minta tepat medan yang anda perlukan
    Perlu diawasi
    Sokongan pembekal dalam pelancongan masih jarang

Integrasi API berbanding pembangunan API

Integrasi API

Menyambungkan produk anda kepada antara muka yang sudah wujud. Pembekal memiliki API; anda membina klien, pemetaan dan peraturan di sekelilingnya.

Pembangunan API

Mencipta antara muka yang digunakan sistem lain untuk menyambung ke produk anda, seperti API B2B yang boleh dipanggil oleh alat ejen anda. Anda memiliki kontrak dan versinya.

Banyak projek pelancongan memerlukan kedua-duanya: platform mengintegrasikan pembekal di satu pihak dan menerbitkan API-nya sendiri kepada ejen dan rakan kongsi di pihak yang lain.

Sebelum dan selepas

Apa yang berubah apabila sistem diintegrasikan

Lima langkah tempahan yang sama, dilakukan secara manual melalui portal pembekal dan dilakukan melalui integrasi API.

Cari

Tanpa integrasiManual

Ejen membuka setiap portal pembekal dan menyalin harga ke dalam sebut harga.

Dengan integrasi APIAutomatik

Satu carian disebarkan ke setiap pembekal yang disambungkan dan mengembalikan satu senarai.

Harga

Tanpa integrasiManual

Markup ditambah dalam hamparan; kadar mungkin sudah berubah apabila sebut harga dihantar.

Dengan integrasi APIAutomatik

Markup, cukai dan peraturan mata wang digunakan pada masa respons; kadar disemak semula sebelum pembayaran.

Tempah

Tanpa integrasiManual

Butiran tetamu ditaip semula ke dalam portal pembekal; kesilapan taip menjadi ralat tempahan.

Dengan integrasi APIAutomatik

Butiran dihantar sekali, disahkan dan disimpan bersama pengesahan pembekal.

Bayar

Tanpa integrasiManual

Pembayaran dikutip secara berasingan dan dipadankan dengan tempahan kemudian.

Dengan integrasi APIAutomatik

Kebenaran, tangkapan dan bayaran balik terikat kepada rujukan tempahan.

Khidmat

Tanpa integrasiManual

Pembatalan dan perubahan bermakna satu lagi log masuk dan satu lagi e-mel.

Dengan integrasi APIAutomatik

Perubahan dan pembatalan berjalan melalui sambungan yang sama dan mengemas kini rekod.

Di mana integrasi API muncul dalam platform pelancongan

Perbendaharaan kata

Istilah yang akan anda temui dalam dokumentasi API

Dua belas perkataan yang muncul dalam portal pembangun hampir setiap pembekal, ditakrifkan mengikut cara ia digunakan dalam pelancongan.

  • API

    Application programming interface: peraturan yang diterbitkan untuk berkomunikasi dengan sesuatu sistem.

  • Pengesahan

    Membuktikan siapa yang memanggil, dengan kunci API, token bearer, tandatangan atau alamat IP yang diluluskan.

  • Pensijilan

    Semakan pembekal terhadap integrasi anda sebelum kelayakan pengeluaran dikeluarkan.

  • Titik akhir

    Satu alamat untuk satu operasi, seperti cari, tempah atau batal.

  • Idempotensi

    Menghantar permintaan yang sama dua kali menghasilkan satu keputusan, yang mengelakkan tempahan dan caj berganda.

  • Pemetaan

    Menterjemah medan, kod dan nama pembekal ke dalam model data platform anda sendiri.

  • Payload

    Data yang dibawa di dalam permintaan atau respons, biasanya JSON atau XML.

  • Had kadar

    Bilangan panggilan yang dibenarkan pembekal sesaat atau sehari sebelum ia mula menolaknya.

  • Permintaan dan respons

    Satu panggilan: platform anda bertanya, pembekal menjawab, dan kedua-dua pihak merekodkannya.

  • Sandbox

    Persekitaran ujian dengan inventori palsu dan kad ujian di mana tiada apa-apa yang benar-benar ditempah atau dicaj.

  • Kod status

    Nombor HTTP yang meringkaskan keputusan: 200 berjaya, 401 tidak dibenarkan, 429 had kadar, 500 ralat pembekal.

  • Webhook

    Panggilan ke arah sebaliknya: pembekal atau gerbang memaklumkan platform anda apabila sesuatu peristiwa berlaku.

Pengujian dan penskopan

Cara integrasi API pelancongan diuji sebelum dilancarkan

Integrasi hanya selesai apabila laluan yang bermasalah berkelakuan dengan betul. Larian ujian terhadap sandbox pembekal merangkumi kes di bawah sebelum pensijilan dan peralihan kepada kelayakan pengeluaran.

jalankan ujian integrasi

sandbox pembekal, sembilan kes

  • OK: Pengesahan dengan kelayakan sah dan tamat tempoh
  • OK: Permintaan tidak sah ditolak dengan ralat yang boleh dibaca
  • OK: Tamat masa pembekal dikendalikan tanpa tempahan tergantung
  • OK: Had kadar dipatuhi dan dicuba semula selepas menunggu
  • OK: Perubahan harga dikesan semasa semakan semula dan ditunjukkan sebelum pembayaran
  • OK: Penghantaran berganda mengembalikan tempahan pertama, bukan yang kedua
  • OK: Pembatalan digunakan dan yuran dikira
  • OK: Bayaran balik dikeluarkan terhadap pembayaran asal
  • OK: Rujukan tempahan, pembayaran dan pembekal diselaraskan

Semua kes lulus, sedia untuk pensijilan

Apa yang diperlukan penskopan daripada anda

  1. 1Perjanjian pembekal, dokumentasi dan kelayakan sandbox
  2. 2Pasaran, mata wang, produk dan peranan pengguna
  3. 3Skop carian, tempahan, perubahan, pembatalan dan bayaran balik
  4. 4Keperluan pensijilan dan proses akses pengeluaran

Sedia untuk menyambungkan pembekal

PHPTRAVELS mengintegrasikan pembekal, gerbang dan alat perniagaan ke dalam platform hos sendiri yang dihantar bersama kod sumbernya. Lihat Harga untuk tiga pelan bayaran sekali, atau tanya kami tentang API tertentu.

Minta demoHubungi kami

Teruskan membaca

Soalan

Soalan integrasi API, dijawab

Jawapan ringkas kepada soalan yang ditanya orang sebelum projek integrasi pertama mereka.

Hubungi jualan

Integrasi API ialah sambungan yang membolehkan dua sistem perisian bertukar data dan mencetuskan tindakan secara automatik. Satu sistem menghantar permintaan berstruktur, satu lagi mengembalikan respons berstruktur, dan kedua-duanya mengikut peraturan yang dipersetujui untuk keselamatan dan data.

Dalam pelancongan ia menyambungkan platform tempahan dengan pembekal penerbangan, hotel, pelancongan atau kereta, gerbang pembayaran dan alat perniagaan. Ia menyokong carian, pengesahan harga, tempahan, pembatalan, bayaran balik dan penyelarasan tanpa menaip semula.

REST ialah gaya seni bina yang biasanya bertukar JSON melalui HTTP. XML ialah format data yang masih lazim dalam kalangan pembekal GDS dan bedbank, selalunya dibalut dalam SOAP. Kontrak dan dokumentasi pembekal menentukan yang mana satu anda gunakan.

Ia bergantung pada akses pembekal, titik akhir dalam skop, pensijilan, peraturan pemetaan dan kes tepi tempahan. Anggaran yang boleh dipercayai datang selepas semakan dokumentasi, kelayakan dan aliran kerja yang anda perlukan.

Uji pengesahan, permintaan sah dan tidak sah, tamat masa, had kadar, perubahan harga, penghantaran berganda, pembatalan, bayaran balik dan penyelarasan. Dalam pengeluaran, setiap permintaan sepatutnya boleh dijejak kepada rujukan tempahan.

Tidak. Integrasi menyambungkan produk anda kepada API sedia ada; pembangunan mencipta antara muka yang disambungkan oleh pihak lain. Platform pelancongan selalunya memerlukan kedua-duanya: pembekal diintegrasikan di satu pihak dan API B2B diterbitkan kepada rakan kongsi di pihak yang lain.

Terokai lagi

Lagi tentang platform