API ali iCal: kateri podatki se prenašajo med koledarji?

Kaj iCal dejansko vsebuje

RFC 5545 opredeljuje iCalendar kot format koledarskih informacij, vključno z dogodki. Začetni in končni datum ter identifikator dogodka so primeri njegovih elementov. Standard opisuje format, ne določa pa, kako pogosto portal prevzame drug koledar.

Pri povezovanju nastanitev se iCal pogosto uporablja za zasedene termine. Airbnb na primer opisuje izvoz povezave do koledarja in uvoz povezave druge storitve. Katere blokade se prenesejo in kako jih prikaže drugi sistem, preverite v navodilih obeh storitev.

Iz koledarskega dogodka ne sklepajte, da so bili preneseni cenik, prodajni pogoji ali celotna rezervacija. Za takšne zahteve poiščite izrecno dokumentacijo, namesto da se zanesete na oznako sinhronizacije.

Zakaj lahko povezava API zajema več podatkov

API določa dovoljene postopke in podatke, ki jih sistem sprejema ali vrača. Booking.com objavlja Rates & Availability API za zmogljivosti, cene in omejitve ter ločen Reservations API za rezervacije in njihove spremembe.

ARI pomeni availability, rates and inventory: razpoložljivost, cene in zmogljivosti. Opisuje področje izmenjave, ne potrjuje pa, da določen izdelek podpira vse cenovne načrte, pravila ali kanale.

S ponudnikom ločeno preverite pošiljanje in prejemanje vsake vrste podatkov. Dostop do enega vmesnika ne pomeni samodejno dostopa do drugih funkcij. Javna dokumentacija portala ne potrjuje zmožnosti vašega pogodbenega paketa.

Razlike, ki vplivajo na vsakodnevno delo

Zamike presojajte glede na način prodaje

Airbnbova navodila opisujejo periodično osveževanje uvoženih koledarjev in ročno osveževanje z omejitvami. To ne pomeni enakega intervala pri drugih storitvah. Pred nastavitvijo preberite aktualna pravila v povezani izvorni dokumentaciji.

Za svojo odločitev zapišite, kako dolgo lahko sprejmete neskladje med dvema prikazoma. Če je isto zadnjo enoto mogoče takoj rezervirati na več portalih, preverite celoten postopek usklajevanja in ravnanje ob odstopanjih.

Hitrost konkretne integracije je treba izmeriti v dogovorjenem preizkusu. Ne navajamo univerzalne hitrosti in ne zagotavljamo, da iCal ali API prepreči vsako dvojno rezervacijo.

Kdaj je lahko iCal dovolj preprosta rešitev

O uporabi iCal razmislite, če potrebujete predvsem prenos zasedenih datumov, sprejemate pravila osveževanja obeh storitev in lahko druge podatke urejate ločeno. To je merilo za lastno presojo, ne priporočilo določene znamke.

Ponazoritveni primer: lastnik želi osebni pregled zasedenosti, cene pa ureja na prodajnem portalu. Uvoz koledarja lahko zadosti tej omejeni potrebi, če prenese ustrezne datume. Preden se nanj zanesete, preverite spremembo in odpoved.

Če potrebujete centralno spreminjanje cen, skupne zmogljivosti več sob ali določene omejitve, ne predpostavljajte, da bo koledar zadostoval. Zahtevajte prikaz potrebnih funkcij in ga primerjajte s ponudbo API.

Kratek načrt preverjanja pred uporabo

To je predlog predstavitve s ponudnikom, ne poročilo o izvedenem testiranju. Uporabite dogovorjeno testno nastanitev ali varen postopek brez dejanskih rezervacij.

1. Zapišite sistem A, sistem B, enoto in podatek, ki ga želite prenesti.
2. Dogovorite se o začetnem stanju in rezultatu nove zasedenosti.
3. Preverite spremembo datumov in odpoved, vključno s ponovno sprostitvijo terminov.
4. Pri ponudbi API ločeno predstavite ceno in potrebne omejitve.
5. Zabeležite čas, stanje in mesto za prijavo neskladja.
6. Določite, kdo spremlja napake in kako prekiniti povezavo brez izgube pregleda rezervacij.

Povežite tehnično zahtevo s ponudbo

Najprej potrdite, kaj povezava naredi, nato zahtevajte ceno za ta obseg. Kalkulator stroškov med sorodnimi temami sešteva vaše zneske; ne predpostavlja, da je katera tehnologija brezplačna ali dražja.

Za širši kontekst zmogljivosti, PMS-a in rezervacij odprite osnovni vodnik. Pravila o virih in povezanosti s ponudniki so v metodologiji in na strani O projektu.