ວັນ 0
ພິສູດການເຂົ້າເຖິງ
ສ້າງ key, ດຳເນີນການຮ້ອງຂໍທີ່ຜ່ານການຢືນຢັນຕົວຕົນໜຶ່ງຄັ້ງ, ແລະ ບັນທຶກການຕອບສະໜອງຄັ້ງທຳອິດພ້ອມກັບ metadata ຂອງມັນ.
ເປີດຂັ້ນຕອນ →ຄູ່ມືຂັ້ນຕອນການເຮັດວຽກ API
ທ່ານຕ້ອງການສ້າງຫຍັງ?
ເລືອກຜົນລັດທີ່ໃກ້ຄຽງກັບວຽກຂອງທ່ານທີ່ສຸດ. ແຕ່ລະເສັ້ນທາງຈະໃຫ້ຄຳຮ້ອງຂໍທີ່ໃຊ້ງານໄດ້ໜຶ່ງລາຍການ, ສິ່ງທີ່ການຕອບສະໜອງຄວນມີ, ວິທີກວດສອບວ່າການເຮັດວຽກສຳເລັດ, ແລະ ຂັ້ນຕອນທີ່ມີປະໂຫຍດຕໍ່ໄປ.
ຫ້າເສັ້ນທາງທີ່ນຳໃຊ້ໄດ້ຈິງ
ເລີ່ມຕົ້ນດ້ວຍຜົນລັດ, ບໍ່ແມ່ນລາຍການ endpoint.
Selected: Harden a client
ເສັ້ນທາງ 1
ດຶງຂໍ້ມູນ macro
ດຶງຂໍ້ມູນອະນຸກົມເວລາທີ່ສະອາດ ແລະ ເກັບຮັກສາ metadata ຂອງແຫຼ່ງທີ່ມາ ແລະ ຄຸນນະພາບໄວ້ຄຽງຄູ່ກັນ.
ເສັ້ນທາງ 2
ວາງແຜນວຽກການເຜີຍແຜ່
ໃຊ້ປະຕິທິນການປ່ອຍຂໍ້ມູນເພື່ອລັນວຽກທີ່ກຳນົດເປົ້າໝາຍອ້ອມຮອບເວລາການເຜີຍແຜ່ທີ່ຮູ້ຈັກ.
ເສັ້ນທາງ 3
ວັດແທກສິ່ງທີ່ເກີດຂຶ້ນນອກເໜືອຈາກການຄາດການ
ລວມການພະຍາກອນກ່ອນການປ່ອຍຂໍ້ມູນເຂົ້າກັບຄ່າທີ່ຖືກເຜີຍແຜ່ ໂດຍບໍ່ເຮັດໃຫ້ເກີດ lookahead bias.
ເສັ້ນທາງ 4
ຮັບການອັບເດດສົດ
ໃຊ້ SSE ເປັນສັນຍານການຍົກເລີກ, ຈາກນັ້ນດຶງຂໍ້ມູນຄົບຖ້ວນຈາກ REST.
ເສັ້ນທາງ 5
ສ້າງແບບຈຳລອງມະຫາພາກ
ປ່ຽນກຸ່ມຕົວຊີ້ວັດທີ່ກ່ຽວຂ້ອງຂະໜາດນ້ອຍ ໃຫ້ເປັນບັດຄະແນນສະກຸນເງິນທີ່ລະບຸແຫຼ່ງທີ່ມາ.
ການທົດລອງໃຊ້ API ຂອງທ່ານເປັນເວລາ 14 ວັນ
ປ່ຽນຈາກການຮ້ອງຂໍຄັ້ງທຳອິດ ໄປສູ່ໜ້າທີ່ການງານທີ່ຄຸ້ມຄ່າທີ່ຈະຮັກສາໄວ້.
ເປົ້າໝາຍບໍ່ແມ່ນການເຂົ້າເບິ່ງທຸກໜ້າຜະລິດຕະພັນ. ແຕ່ແມ່ນການເຮັດວຽກ API ທີ່ຜ່ານການຢືນຢັນຕົວຕົນໃຫ້ສຳເລັດ, ກັບມາໃນມື້ອື່ນ, ແລະ ອອກໄປພ້ອມກັບຊຸດຂໍ້ມູນ ຫຼື ຂະບວນການເຮັດວຽກຂອງແອັບພລິເຄຊັນທີ່ເຮັດຊ້ຳໄດ້.
ວັນທີ 1-2
ເຮັດໃຫ້ຄຳຂໍມີຄວາມໜ້າເຊື່ອຖື
ແກ້ໄຂບັນຫາການຢືນຢັນຕົວຕົນ ຫຼື ບັນຫາການກັ່ນຕອງ ແລະ ປ່ຽນສະຄຣິບທຳອິດໃຫ້ເປັນວຽກທີ່ຕັ້ງຊື່ໄດ້ ແລະ ເຮັດຊ້ຳໄດ້.
ເປີດຂັ້ນຕອນ →ວັນທີ 3-4
ເພີ່ມເວລາການປ່ອຍຂໍ້ມູນ
ໃຊ້ປະຕິທິນເປັນ endpoint ຕະກູນທີສອງ ແລະ ກຳນົດເວລາການເຮັດວຽກຂອງ API ທີ່ມີປະໂຫຍດຄັ້ງຕໍ່ໄປ.
ເປີດຂັ້ນຕອນ →ວັນ 5-7
ສ້າງຜົນລັດການວິໄຈ
ເພີ່ມຄວາມຄາດຫວັງ ຫຼື ກຸ່ມສರಣະ macro ຂະໜາດນ້ອຍ, ຈາກນັ້ນສ້າງການປຽບທຽບ, ຕາຕະລາງ, ຫຼື ໃບຄະແນນທີ່ບັນທຶກໄວ້ໜຶ່ງລາຍການ.
ເປີດຂັ້ນຕອນ →ວັນ 8-10
ເຮັດໃຫ້ການອັບເດດເປັນອັດຕະໂນມັດ
ເລືອກ REST, SSE, ຫຼື webhooks ທີ່ກຳນົດເວລາໄວ້ ແລະ ສຳເລັດການລັນ API ທີ່ສຳເລັດອີກຄັ້ງໃນວັນອື່ນ.
ເປີດຂັ້ນຕອນ →ວັນທີ 11-13
ເຮັດໃຫ້ client ແຂງແຮງຂຶ້ນ
ເພີ່ມການກຳນົດເວລາໝົດອາຍຸ, ການລອງໃໝ່ແບບຈຳກັດ, ການກວດສອບການຕອບສະໜອງ, ການບັນທຶກປ້ຳທີ່ປອດໄພ, ແລະ ການຕິດຕາມຂໍ້ມູນທີ່ເກົ່າ.
ເປີດຂັ້ນຕອນ →ວັນ 14
ທົບທວນຫຼັກຖານ
ຢືນຢັນວ່າ API ໃຫ້ວຽກທີ່ສາມາດເຮັດຊ້ຳໄດ້ທີ່ທີມຂອງທ່ານຈະຮັກສາໄວ້, ຈາກນັ້ນເລືອກຊຸດຂໍ້ມູນ ຫຼື workflow ຂອງແອັບພລິເຄຊັນຖັດໄປ.
ເປີດຂັ້ນຕອນ →Production readiness
ເຮັດໃຫ້ຄລາຍເອນ API ພ້ອມສຳລັບການຜະລິດ
Production reliability comes from treating status codes differently, keeping retries bounded, reusing ETags, and choosing scheduled REST, SSE, or webhooks for the job.
ຕົວຢ່າງທີ່ໃຊ້ງານໄດ້
ເກັບຮັກສາຄີຂອງທ່ານໃນ FXMD_API_KEY; ຫ້າມວາງມັນລົງໃນ source control ໂດຍເດັດຂາດ.
import os
import requests
from urllib3.util.retry import Retry
session = requests.Session()
retry = Retry(total=3, backoff_factor=0.5, status_forcelist=(429, 502, 503, 504))
session.mount("https://", requests.adapters.HTTPAdapter(max_retries=retry))
response = session.get(
"https://api.fxmacrodata.com/v1/announcements/eur/inflation",
params={"api_key": os.environ["FXMD_API_KEY"], "limit": 5},
headers={"Accept-Encoding": "gzip"},
timeout=(3.05, 20),
)
response.raise_for_status()ຜົນລັດທີ່ຄາດໄວ້: A bounded client that handles transient failures without retry storms and is ready to add ETag-based conditional refreshes.
ເມື່ອສະຄຣິບທຳອິດກາຍເປັນລະບົບທີ່ໃຊ້ງານຈິງ
ການແກ້ໄຂບັນຫາ ແລະ ຄຳແນະນຳການຜະລິດ
ໃຊ້ຄູ່ມືເຫຼົ່ານີ້ເມື່ອການຕອບສະໜອງລົ້ມເຫຼວ, ບໍ່ມີຂໍ້ມູນສົ່ງກັບມາ, ຫຼື ຕ້ອງການການຄວບຄຸມລະດັບ production ເຊັ່ນ: caching, timeouts, retries, ແລະ event delivery.
| ຄູ່ມື | ໃຊ້ວ່າມັນເມື່ອ | ເລີ່ມຕົ້ນ |
|---|---|---|
| ວິເຄາະການຕອບສະໜອງທີ່ລົ້ມເຫຼວ ຫຼື ວ່າງເປົ່າ | ແຍກບັນຫາການຢືນຢັນຕົວຕົນ, ການເຂົ້າເຖິງ, ເສັ້ນທາງ, ຂໍ້ຈຳກັດອັດຕາ, ແລະ ຄວາມພ້ອມຂອງຂໍ້ມູນ ໂດຍບໍ່ຕ້ອງເປີດເຜີຍຄີຂອງທ່ານ. | ເປີດຄູ່ມື → |
| ເຮັດໃຫ້ຄລາຍເອນ API ພ້ອມສຳລັບການຜະລິດ | ເພີ່ມ timeouts, ການລອງໃໝ່ແບບຈຳກັດ, ການເຮັດ caching, ການຮ້ອງຂໍແບບມີເງື່ອນໄຂ, ແລະ ຮູບແບບການສົ່ງຂໍ້ມູນທີ່ຖືກຕ້ອງ. | ເປີດຄູ່ມື → |