Fomu ya AJAX inatarajia JSON lakini inapokea HTML: fuata jibu hatua kwa hatua

Fomu inatumwa, kizunguzungu kinaonekana, na konsoli inasema kuna alama < isiyotarajiwa katika JSON kwenye nafasi 0. Ukurasa wenyewe unapakia vizuri, ndiyo sababu hisia ya kwanza ni kulaumu kichanganuzi au handaki. Kwa kawaida hakuna hata mmoja anayehusika: kutuma ni ombi tofauti na kupakia ukurasa, na limerudi na kitu ambacho si JSON. Fanya kazi kwa mpangilio ambao kivinjari hukifunua kweli, kwa sababu majibu manne yanayowezekana yanahitaji marekebisho manne tofauti.

Hatua 1: kamata utumaji uliotokea kweli

Fungua paneli ya Mtandao kabla ya kutuma, weka kumbukumbu ihifadhi maingizo kati ya urambazaji, kisha fanya utumaji mmoja wa majaribio usio na madhara kwenye akaunti unayoruhusiwa kutumia. Chagua ombi lililoanzishwa na fomu yenyewe, si ombi la hati la ukurasa.

Kuwa mwangalifu na vichujio. Kichujio cha XHR au Fetch ni rahisi, lakini ikiwa mfumo bado unatuma kupitia iframe iliyofichwa au fomu iliyoundwa kwa nguvu, kichujio kitaficha ombi moja muhimu. Tuma mara moja bila kichujio kwanza na uone kilichojitokeza.

Kwa ombi lililochaguliwa, andika mambo sita kabla ya tafsiri yoyote: mbinu, URL kamili pamoja na mfuatano wa hoja, hali, mnyororo wa uelekezaji upya, Content-Type ya jibu, na mistari ya kwanza ya mwili. Marejeo ya paneli ya Mtandao ya Chrome DevTools inashughulikia mitazamo ya Headers, Response na Initiator ambapo vitu hivi viko, na paneli zinazolingana katika vivinjari vingine zinaonyesha sehemu hizo hizo.

Hatua 2: thibitisha kwamba ni ombi unalofikiri

Idadi ya kushangaza ya hitilafu za JSON kwa kweli ni hitilafu za uelekezaji. Ikiwa mshughulikiaji wa utumaji anatupa hitilafu kabla ya kuita preventDefault, kivinjari hufanya POST ya asili ya fomu kwenda anwani inayosemwa na sifa ya action, na seva hujibu kwa ukurasa kamili wa HTML. Mshughulikiaji hauendeshwi kamwe, kwa hiyo JSON haikuombwa kamwe.

Linganisha URL iliyo kwenye paneli na URL ambayo JavaScript yako inaiita. Tafuta uelekezaji upya unaoishia mahali pengine, mkwaju wa mwisho unaokosekana au wa ziada, kutofautiana kwa mbinu, au fomu inayotuma kwenye njia linganifu kutoka ukurasa uliohamishwa. Fuata mnyororo wa uelekezaji hadi mwisho na uandike URL ya mwisho, si ya kwanza.

Kisha angalia mwanzilishi. Ikiwa ombi lilitoka kwenye urambazaji wa hati badala ya script yako, tayari umepata tatizo, na hakuna mabadiliko kwenye kichanganuzi cha jibu yatakayosaidia.

Hatua 3: gawanya matokeo katika makundi manne

Kila matokeo huangukia katika moja tu ya haya, na kundi huamua wapi kuangalia baadaye.

Safu za kati ndizo ambazo watu huzitambua vibaya, kwa sababu hali ni 200. Ukurasa wa kuingia unaofikiwa baada ya uelekezaji upya ni jibu zuri kabisa la HTTP na hati mbaya sana ya JSON. Aina ya maudhui application/json hairekebishi hilo: ni lebo tu, na mwili uliowekewa lebo isiyo sahihi bado hauwezi kuchanganuliwa. Ufikiaji umezuiwa ni safu inayoonekana kama ombi lililokamilika: paneli inaonyesha hali, lakini sera ya vyanzo mbalimbali inashikilia mwili, kwa hiyo kwa script inayoiita ni bure kama muda kuisha.

Safu ya nne ni ya kawaida vile vile kwenye mikusanyiko ya zamani ya PHP na mifumo. Onyo la kutoendelea linalochapishwa kabla ya mzigo uliosimbwa hutoa mwili ambao hakuna kichanganuzi cha JSON kitakaoupokea, na mara nyingi onyo hilo ndilo maelezo yote.

Hatua 4: soma hitilafu ya kichanganuzi kwa maana halisi

Maandishi ya hitilafu yanataja herufi ya kwanza iliyovunja uchanganuzi, na hiyo kwa kawaida hutambua kundi bila ubishi wowote.

Mwili mtupu wenye 200 ni kisa chake: kituo cha mwisho kilifanya kazi, hakikutoa kitu, na kitu kingine chini kilichukua hilo kama mafanikio. Hiyo ni kushindwa kwa mkataba wa programu na si kwa usafirishaji, na mahali pake ni hatua inayofuata, si kwenye proksi. Firefox na Safari huyaeleza yale yale mashindano manne kwa namna nyingine, kwa hiyo linganisha kwa herufi au mwili mtupu na si kwa mfuatano kamili.

Hatua 5: rekebisha tabaka ambalo ushahidi unaonyesha

Kwa tatizo la uelekezaji, rekebisha ombi: rekebisha action, zuia mshughulikiaji kuanguka, linganisha kituo cha mwisho na mbinu, na jaribu tena. Kwa tatizo la uwakilishi, rekebisha kile kilichozalisha mwili, na ujue kwa nini hati ya hitilafu inarudi mahali data ilitarajiwa. Kwa tatizo la mkataba, soma muundo halisi unaotarajiwa na mfumo kwa toleo unalolifanyia kazi, na uunde jibu kulingana na hilo badala ya kulegeza mteja.

Jibu lenye ufikiaji uliozuiwa linahitaji mzunguko wake, kwa sababu ombi lenyewe linaweza kuwa sahihi na mwili unaweza usifike kamwe kwenye msimbo wako. Linganisha Access-Control-Allow-Origin ya jibu na Origin kamili iliyotumwa na kivinjari, na kumbuka kwamba wildcard haitoshelezi ombi lenye vitambulisho. Oanisha credentials: 'include' kwa mteja na Access-Control-Allow-Credentials: true kwa seva, na angalia ikiwa wito ulitumia hali ya no-cors, ambapo mwili usio wazi ni matokeo yaliyoandikwa na si kasoro.

Kubadilisha kichanganuzi na kitu kinachovumilia zaidi ndiyo marekebisho pekee yanayopaswa kuepukwa. Kutathmini jibu kama msimbo, au kumenya maandishi hadi lichanganuliwe, huficha kutokulingana kwa mkataba na kuongeza uso wa kuingiza badala ya ukimya. Vile vile, hali lazima ichunguzwe kando na mwili: 200 iliyo na kitu cha hitilafu katika ngazi ya programu ni kawaida katika API nyingi na lazima ishughulikiwe kwa kusoma mzigo.

Unapohitaji msaada wa mtu mwingine, shiriki kumbukumbu ndogo — mbinu, URL, hali, URL ya mwisho baada ya uelekezaji upya, aina ya maudhui ya jibu, umbo la mwili na mkataba unaotarajiwa — badala ya mauzo ghafi. Kumbukumbu za mtandao zina vidakuzi, tokeni, mifuatano ya hoja na data binafsi iliyokuwa kwenye fomu, na kisafishaji cha kiotomatiki si ukaguzi.

• Kamata ombi bila kichujio kabla ya kubadilisha msimbo wowote.
• Thibitisha kwamba mwanzilishi alikuwa script yako na URL ya mwisho ni kituo chako cha mwisho.
• Gawanya jibu katika makundi kabla ya kugusa kichanganuzi.
• Rekebisha uelekezaji, ufikiaji, uwakilishi au mkataba, na kamwe si kwa kulegeza kichanganuzi.