Dërgoni një regjistrim në numëratorin telefonik

Dërgoni një regjistrim në numëratorin e operatorit

Dërgoni emrin dhe adresën që do të përdoren për regjistrimin në numërator të një numri telefonik të pranueshëm që zotëroni në MultiTEL. Ky është një përditësim me pagesë tek operatori, jo një kërkim i emrit të telefonuesit, një regjistrim në një libër privat adresash apo një përditësim i përgjithshëm i fushës LIDB të inventarit të portalit.

Dërgoni vetëm të dhënat që klienti ka autorizuar për regjistrimin në numërator. Konfirmoni që operatori e mbështet shërbimin për numrin përpara se të përdorni këtë rrugë të vjetër. Komponenti i shqyrtuar i përpunimit nuk verifikon pranueshmërinë e ofruesit ose formatin ndërkombëtar të numrit; kërkesa e tij drejtuar operatorit supozon një numër të Amerikës së Veriut dhe heq shifrën e parë të ruajtur.

Kërkesat për llogarinë dhe numrin

Përdorni një llogari API të aktivizuar nëpërmjet HTTPS, nga një adresë IP burimi e lejuar. Numri i saktë duhet të përputhet me një rresht të paanuluar të një numri të blerë që i përket asaj llogarie. Përdorni të gjitha shifrat ndërkombëtare të numrit në inventarin tuaj, si formati me kodin e shtetit 1 për një numër të mbështetur të Amerikës së Veriut. Mos përdorni identifikuesin e një plani tarifor, UUID të numrit ose një numër që i përket një llogarie tjetër.

Kërkesë POST me të dhëna formulari

Vendoseni NUMBER në vlerën e numrit që zotëroni. Zëvendësoni shembullin fiktiv me të dhënat e autorizuara për regjistrim. Kjo rrugë lexon fushat e formularit nga POST; ajo nuk analizon një trup kërkese në formatin application/json.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"

Drejtimet dhe adresa në shembull janë vlera ilustruese, jo një adresë postare e rekomanduar. Mos shtoni një drejtim fiktiv në të dhënat reale të klientit. Kontrollet e fushave të detyrueshme nga API janë sipërfaqësore: ato nuk përcaktojnë nëse një adresë është e vlefshme ose e pranuar nga operatori, dhe faqja e vjetër zbatonte kërkesa të ndryshme për formularin.

Implementimi mund të lëshojë një paralajmërim për mungesën e një çelësi në një varg kur një pjesë opsionale që tregon drejtimin mungon ose është bosh. Nëse përgjigjja ka format të gabuar ose operatori e refuzon adresën, ruani referencën e kërkesës dhe kërkojini shërbimit të mbështetjes të konfirmojë regjistrimin, në vend që të dërgoni vazhdimisht variante adresash të ndryshuara sipas hamendësimeve.

Sjellja e tarifimit dhe e riprovimit

Komponenti i shqyrtuar i përpunimit kontrollon nëse ka të paktën 10.00 njësi të gjendjes së llogarisë përpara se të kontaktojë operatorin. Pasi operatori raporton sukses dhe përditësimi lokal i numrit raporton sukses, ai zbret 10.00 nga gjendja e llogarisë dhe regjistron një transaksion për konfigurimin e regjistrimit në numërator. Këto janë shumat që zbaton implementimi aktual, jo një propozim i ri çmimesh; përpara dërgimit, konfirmoni monedhën e zbatueshme të faturimit dhe shërbimin e mbështetur sipas kushteve të llogarisë suaj.

Veprimi nuk ka çelës idempotence, mbrojtje kundër porosive të dyfishta ose transaksion që përfshin dërgimin tek operatori, përditësimin lokal dhe faturimin. Një kërkesë e përsëritur që përfundon me sukses mund të shkaktojë një tjetër dërgim tek operatori dhe një tjetër tarifim. Mbarimi i afatit të pritjes ose një gabim i API nuk provon që operatori e ka refuzuar kërkesën e mëparshme: ofruesi mund ta ketë pranuar përpara se të dështonte një përditësim lokal.

Përgjigjja

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

Përgjigjja normale e suksesit përmban një varg bosh në fushën response dhe nuk kthen identifikues regjistrimi ose hollësi për përfundimin. Kjo do të thotë që rrjedhat e operatorit dhe të përditësimit lokal raportuan sukses; nuk provon publikimin në çdo numërator të jashtëm, përhapjen e menjëhershme ose shfaqjen e ardhshme të identitetit të telefonuesit.

Gabimet e sistemit të vjetër

Lexoni si statusin HTTP, ashtu edhe fushat në JSON status.code/status.msg. Autentikimi dhe kufizimet e adresës IP të burimit mund të pengojnë gjithashtu marrjen e një përgjigjeje të përdorshme. Mos përdorni GET ose parametra të vargut të pyetjes për të kërkuar një përditësim vetëm sepse komponenti i vjetër i përpunimit nuk ka një kontroll të shprehur të metodës HTTP.

Verifikoni përpara se të provoni sërish

1. Konfirmoni numrin që zotëroni, pranueshmërinë e operatorit, të dhënat e autorizuara të regjistrimit dhe tarifën përpara se të dërgoni kërkesën.
2. Dërgojeni vetëm një herë dhe ruani rezultatin në anën e llogarisë pa ekspozuar adresën e klientit në regjistra publikë ose në sisteme analitike.
3. Kontrolloni regjistrimin e ruajtur dhe historikun e transaksioneve nëpërmjet rrjedhës së mbështetur të punës së llogarisë ose shërbimit të mbështetjes. Prisni kohën e përpunimit të konfirmuar nga operatori; kjo API nuk përcakton asnjë afat të garantuar për përhapjen.
4. Kur rezultati është i pasigurt, kërkojini shërbimit të mbështetjes të kontrollojë përputhjen mes porosisë tek operatori dhe faturimit lokal përpara se të provoni sërish. Një kërkesë e përsëritur nuk është një kontroll idempotent i statusit.