ਕੀ ਸਮਾਂ ਸਮਾਪਤ ਹੋਈ ਉਹ ਸਬਮਿਟ ਸੱਚਮੁੱਚ ਤੁਹਾਡਾ ਕੰਮ ਸੰਭਾਲ ਸਕੀ?

ਬਟਨ ਘੁੰਮ ਰਿਹਾ ਹੈ, ਟੈਬ ਗਲਤੀ ਦਿਖਾ ਰਹੀ ਹੈ, ਅਤੇ ਦਸ ਮਿੰਟ ਭਰਿਆ ਤੁਹਾਡਾ ਫਾਰਮ ਗਾਇਬ ਹੈ। ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕਨੈਕਸ਼ਨ ਟੁੱਟਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਤ ਪਹੁੰਚੀ ਜਾਂ ਨਹੀਂ। ਇਸ ਅਣਜਾਣ ਨੂੰ ਅਸਫਲਤਾ ਮੰਨਣਾ ਹੀ ਨਕਲੀ ਟਿੱਪਣੀਆਂ, ਦੁਹਰੇ ਆਰਡਰ ਅਤੇ ਵਾਰ-ਵਾਰ ਆਉਣ ਵਾਲੀਆਂ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ ਬਹਾਲੀ ਕਰੋ: ਟੈਕਸਟ ਰੱਖੋ, ਨਤੀਜਾ ਲੱਭੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੈਅ ਕਰੋ ਕਿ ਦੂਜੀ ਸਬਮਿਟ ਮਨਜ਼ੂਰ ਹੈ ਜਾਂ ਨਹੀਂ।

ਟੈਕਸਟ ਅਤੇ ਸਮਾਂ-ਛਾਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੇਜ ਤੋਂ ਸਮੱਗਰੀ ਕਾਪੀ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਖੇਤਰ ਵਿੱਚ ਰੱਖਿਆ ਡਰਾਫਟ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਸਮਾਂ, ਤੁਸੀਂ ਜਿਸ ਪੇਜ ’ਤੇ ਸੀ ਅਤੇ ਕੀਤੀ ਕਾਰਵਾਈ ਲਿਖ ਲਓ, ਕਿਉਂਕਿ ਇਹ ਤਿੰਨ ਵੇਰਵੇ ਹੀ ਬਾਕੀ ਜਾਂਚ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ। ਜੇ ਟੈਬ ਅਜੇ ਖੁੱਲ੍ਹੀ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਐਂਟਰੀ ਪੜ੍ਹਨ ਤੱਕ ਉਹ ਖੁੱਲ੍ਹੀ ਰਹਿਣ ਦਿਓ। ਟੈਕਸਟ ਸੰਭਾਲਣ ਦਾ ਕੋਈ ਖਰਚ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਗੁਆਉਣ ਦਾ ਖਰਚ ਪੂਰਾ ਕੰਮ ਹੈ।

ਫਿਰ ਉਹ ਦੋ ਕਿਸਮਾਂ ਦੀਆਂ ਖਰਾਬੀਆਂ ਵੱਖ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਵੇਖ ਸਕਦੇ ਹੋ। ਬੇਨਤੀ ਦੇ ਵਿਚਕਾਰ ਟੁੱਟਿਆ ਕਨੈਕਸ਼ਨ ਅਤੇ ਗਲਤੀ ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਰਵਰ ਨੈੱਟਵਰਕ ਪੈਨਲ ਵਿੱਚ ਵੱਖਰੇ ਦਿਖਦੇ ਹਨ, ਅਤੇ ਐਪ ਦੇ ਫੈਸਲੇ ਬਾਰੇ ਕੁਝ ਸਿਰਫ਼ ਦੂਜਾ ਹੀ ਦੱਸਦਾ ਹੈ।

ਐਪ ਦੇ ਆਪਣੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਨਤੀਜਾ ਲੱਭੋ

ਨਤੀਜਾ ਦਿਖਾਉਣ ਵਾਲਾ ਪੜ੍ਹਨ ਦ੍ਰਿਸ਼ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ: ਟਿੱਪਣੀਆਂ ਦੀ ਸੂਚੀ, ਆਰਡਰ ਦਾ ਇਤਿਹਾਸ, ਟਿਕਟ ਦੀ ਕਤਾਰ ਜਾਂ ਤੁਸੀਂ ਸੰਪਾਦਿਤ ਕਰ ਰਹੇ ਰਿਕਾਰਡ। ਸਭ ਤੋਂ ਨਵੀਂ ਐਂਟਰੀ ਦੀ ਬਜਾਏ ਖਾਤਾ, ਮੰਜ਼ਿਲ, ਸਮਾਂ ਅਤੇ ਸਮੱਗਰੀ ਨਾਲ ਮਿਲਾਓ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਬਾਅਦ ਕੋਈ ਹੋਰ ਲਿਖ ਸਕਦਾ ਹੈ। ਪਿਛੋਕੜ ਵਾਲੇ ਕੰਮ ਲਈ, ਕਨੈਕਟੀਵਿਟੀ ਜਾਂਚ ਵਜੋਂ ਨਵਾਂ ਓਪਰੇਸ਼ਨ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਮੌਜੂਦਾ ਹਵਾਲਾ ਅਤੇ ਉਸਦੀ ਸਥਿਤੀ ਲੱਭੋ।

ਜੇ ਨਤੀਜਾ ਉੱਥੇ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪੂਰਾ ਕਰ ਲਿਆ ਅਤੇ ਗਲਤੀ ਲਿਖਤ ਦੀ ਨਹੀਂ, ਜਵਾਬ ਦੇ ਰਾਹ ਦੀ ਹੈ। ਜੇ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਸੰਭਾਵਨਾ ਰੱਖੋ ਕਿ ਐਪ ਨੇ ਅਜੇ ਇਸਨੂੰ ਪੱਕਾ ਨਹੀਂ ਕੀਤਾ: ਕਤਾਰ ਵਿੱਚ ਪਿਆ ਕੰਮ, ਦੇਰੀ ਨਾਲ ਆਉਣ ਵਾਲਾ ਪੜ੍ਹਨ ਦ੍ਰਿਸ਼ ਜਾਂ ਪਿੱਛੇ ਰਹਿ ਗਈ ਕਾਪੀ ਸਫਲ ਲਿਖਤ ਨੂੰ ਕੁਝ ਸਮਾਂ ਲੁਕਾ ਸਕਦੀ ਹੈ।

ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਨਿਸ਼ਚਿਤ ਦੂਜੀ ਨਜ਼ਰ ਦਿਓ, ਅਤੇ ਦੋਵੇਂ ਜਾਂਚਾਂ ਦਾ ਸਮਾਂ ਲਿਖੋ। ਵੀਹ ਸਕਿੰਟ ਦੇ ਅੰਤਰ ਨਾਲ ਕੀਤੀਆਂ ਦੋ ਜਾਂਚਾਂ ਦਸ ਮਿੰਟ ਦੇ ਅੰਤਰ ਨਾਲ ਕੀਤੀਆਂ ਦੋ ਜਾਂਚਾਂ ਨਾਲੋਂ ਬਹੁਤ ਕਮਜ਼ੋਰ ਸਬੂਤ ਹਨ।

ਤੈਅ ਕਰੋ ਕਿ ਦੂਜੀ ਸਬਮਿਟ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ

ਜਵਾਬ ਕਾਰਵਾਈ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੇ ਸਬਰ ’ਤੇ ਨਹੀਂ। HTTP ਉਹਨਾਂ ਢੰਗਾਂ ਨੂੰ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਸੇ ਇੱਛਤ ਪ੍ਰਭਾਵ ਨਾਲ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ, ਅਤੇ ਦੂਜੀ ਕਿਸਮ ਦੀ ਸਵੈਚਾਲਿਤ ਦੁਹਰਾਈ ਦੇ ਵਿਰੁੱਧ ਸਲਾਹ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਇਹ ਨਾ ਪਤਾ ਹੋਵੇ ਕਿ ਅਰਥ-ਸ਼ਾਸਤਰ ਇਸਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਟਿੱਪਣੀ ਬਣਾਉਣਾ, ਆਰਡਰ ਦੇਣਾ ਅਤੇ ਭੁਗਤਾਨ ਭੇਜਣਾ ਆਮ ਤੌਰ ’ਤੇ ਦੂਜੇ ਸਮੂਹ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਇਸੇ ਲਈ ਸਫਲ ਦਿਖਣ ਵਾਲਾ ਦੂਜਾ ਕਲਿੱਕ ਪਹਿਲੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਜੇ ਤੁਸੀਂ ਕਲਾਇੰਟ ਸੰਭਾਲਦੇ ਹੋ, ਤਾਂ API ਵੱਲੋਂ ਦਰਜ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਜਾਂ ਇਡੈਂਪੋਟੈਂਸੀ ਵਿਵਸਥਾ ਵਰਤੋ, ਅਤੇ ਹਰ ਕੋਸ਼ਿਸ਼ ਲਈ ਨਵੀਂ ਕੁੰਜੀ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਉਸੇ ਤਾਰਕਿਕ ਕਾਰਵਾਈ ਨਾਲ ਜੋੜੋ। ਟ੍ਰੇਸਿੰਗ ਲਈ ਵਰਤਿਆ ਬੇਨਤੀ ਪਛਾਣਕਰਤਾ ਨਕਲ ਦਬਾਉਣ ਦੀ ਕੁੰਜੀ ਨਹੀਂ ਹੈ, ਜਦੋਂ ਤੱਕ ਸਰਵਰ ਇਸਨੂੰ ਅਜਿਹਾ ਨਹੀਂ ਮੰਨਦਾ।

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

ਕੁੰਜੀ ਸਿਰਫ਼ ਤਦ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਸੇਵਾ ਇਸਨੂੰ ਕਾਰਵਾਈ ਨਾਲ ਸੰਭਾਲਦੀ ਹੈ ਅਤੇ ਦੁਹਰਾਉਣ ’ਤੇ ਮੂਲ ਨਤੀਜਾ ਵਾਪਸ ਦਿੰਦੀ ਹੈ। ਉਤਪਾਦਨ ਵਿੱਚ ਇਸ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਟੇਜਿੰਗ ਐਂਡਪੌਇੰਟ ’ਤੇ ਇਹ ਵਿਵਹਾਰ ਪਰਖੋ।

ਦੁਬਾਰਾ ਕੁਝ ਦਬਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਬੂਤ ਇਕੱਠੇ ਕਰੋ

ਗਲਤੀ ਦੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਦੀ ਬਜਾਏ ਨੈੱਟਵਰਕ ਐਂਟਰੀ ਰੱਖੋ। ਬੇਨਤੀ ਦਾ ਢੰਗ, URL, ਜਵਾਬ ਜਾਂ ਸਮਾਂ-ਸੀਮਾ ਅਤੇ ਇਹ ਕਦੋਂ ਹੋਇਆ, ਇਹੀ ਹੈ ਜੋ ਪ੍ਰਬੰਧਕ ਐਪ ਦੇ ਰਿਕਾਰਡ ਨਾਲ ਮਿਲਾ ਸਕਦਾ ਹੈ। ਐਂਟਰੀ ਨੂੰ ਹੁਕਮ ਵਜੋਂ ਨਿਰਯਾਤ ਜਾਂ ਕਾਪੀ ਕਰੋ, ਪਰ ਤਦ ਹੀ ਜਦੋਂ ਉਸ ਤੋਂ ਬਾਅਦ ਕਾਪੀ ਵਿੱਚੋਂ ਕੂਕੀਜ਼, ਅਧਿਕਾਰ ਹੈਡਰ ਅਤੇ ਕੋਈ ਵੀ ਨਿੱਜੀ ਸਮੱਗਰੀ ਹਟਾ ਦਿਓ। ਆਪਣਾ ਸੈਸ਼ਨ ਅਭੰਗ ਰੱਖੋ, ਅਤੇ ਫੜੀ ਗਈ ਪਛਾਣ-ਪੱਤਰ ਵਾਲੀ ਬੇਨਤੀ ਨੂੰ ਕਦੇ ਵੀ ਸ਼ਾਰਟਕਟ ਵਜੋਂ ਦੁਬਾਰਾ ਨਾ ਚਲਾਓ।

ਸੇਵਾ ਦੇ ਮਾਲਕ ਨੂੰ ਇੱਕ ਠੋਸ ਸਵਾਲ ਪੁੱਛੋ: ਇਸ ਸਮੱਗਰੀ ਨਾਲ ਇਸ ਸਮੇਂ ਕਾਰਵਾਈ ਸਫਲ ਹੋਈ, ਅਤੇ ਇਸਦਾ ਕੋਈ ਹਵਾਲਾ ਹੈ? ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਹੈ, ਪਰ "ਸਾਈਟ ਟੁੱਟ ਗਈ" ਦਾ ਜਵਾਬ ਨਹੀਂ ਹੈ।

ਇਸ ਅਭਿਆਸ ਦਾ ਮਕਸਦ ਇਹ ਸਥਾਪਿਤ ਕਰਨਾ ਹੈ ਕਿ ਕਾਰਵਾਈ ਬਿਲਕੁਲ ਇੱਕ ਵਾਰ ਹੋਈ। ਜਿਸ ਗਲਤੀ-ਸੰਦੇਸ਼ ਨੂੰ ਤੁਸੀਂ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ, ਉਹ ਉਸ ਰਿਕਾਰਡ ਵਾਂਗ ਨਹੀਂ ਜਿਸ ’ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਕੁਝ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਦੂਜਾ ਹੀ ਚਾਹੀਦਾ ਹੈ।