ດັ່ງນັ້ນມັນແມ່ນ RAML ຫຼື OAS (Swagger)?

ໃນໂລກທີ່ມີການເຄື່ອນໄຫວຂອງບໍລິການຈຸລະພາກ, ສິ່ງໃດສາມາດປ່ຽນແປງໄດ້—ອົງປະກອບໃດນຶ່ງສາມາດຖືກຂຽນໃໝ່ໃນພາສາອື່ນ, ໂດຍໃຊ້ກອບ ແລະສະຖາປັດຕະຍະກຳທີ່ແຕກຕ່າງກັນ. ສັນຍາເທົ່ານັ້ນບໍ່ຄວນປ່ຽນແປງເພື່ອໃຫ້ບໍລິການຈຸລະພາກສາມາດພົວພັນກັບພາຍນອກໄດ້ໂດຍພື້ນຖານຖາວອນ, ໂດຍບໍ່ຄໍານຶງເຖິງການປ່ຽນແປງພາຍໃນ. ແລະໃນມື້ນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບບັນຫາຂອງພວກເຮົາໃນການເລືອກຮູບແບບສໍາລັບການອະທິບາຍສັນຍາແລະແບ່ງປັນສິ່ງປະດິດທີ່ພວກເຮົາພົບເຫັນ.

ກະກຽມໄປສະນີ Anna Melekhova и Vladimir Lapatin

ການບໍລິການຈຸລະພາກ. ເມື່ອພັດທະນາ Acronis Cyber ​​​​Cloud, ພວກເຮົາຮູ້ວ່າພວກເຮົາບໍ່ສາມາດຫນີພວກເຂົາ. ແລະການອອກແບບ microservice ແມ່ນເປັນໄປບໍ່ໄດ້ໂດຍບໍ່ມີການເຮັດສັນຍາຢ່າງເປັນທາງການ, ເຊິ່ງເປັນຕົວແທນຂອງການໂຕ້ຕອບຂອງ microservice.

ແຕ່ເມື່ອຜະລິດຕະພັນມີຫຼາຍກວ່າຫນຶ່ງອົງປະກອບ, ແລະການພັດທະນາສັນຍາກາຍເປັນກິດຈະກໍາປົກກະຕິ, ທ່ານບໍ່ສາມາດເລີ່ມຕົ້ນຄິດກ່ຽວກັບການເພີ່ມປະສິດທິພາບຂອງຂະບວນການ. ມັນຈະກາຍເປັນທີ່ຊັດເຈນວ່າການໂຕ້ຕອບ (ສັນຍາ) ແລະການປະຕິບັດ (ບໍລິການຈຸລະພາກ) ຕ້ອງກົງກັນ, ອົງປະກອບທີ່ແຕກຕ່າງກັນຕ້ອງເຮັດສິ່ງດຽວກັນໃນລັກສະນະດຽວກັນ, ແລະວ່າໂດຍບໍ່ມີການຕັດສິນໃຈສູນກາງຂອງການຕັດສິນໃຈທັງຫມົດເຫຼົ່ານີ້, ແຕ່ລະທີມຈະຖືກບັງຄັບໃຫ້. ໃຊ້ເວລາອີກເທື່ອຫນຶ່ງແລະອີກເທື່ອຫນຶ່ງເພື່ອໃຫ້ໄດ້ຮັບໃຫ້ເຂົາເຈົ້າ.

ແຜນວາດ Amazon microservices ຈາກ tweet Werner Vogelis, CTO Amazon
ຄວາມເດືອດຮ້ອນແມ່ນຫຍັງ? ໃນຄວາມເປັນຈິງ, ມີສອງວິທີທີ່ຈະພົວພັນກັບບໍລິການຈຸລະພາກ - HTTP Rest ແລະ gRPC ຈາກ Google. ບໍ່ຕ້ອງການທີ່ຈະຕິດຢູ່ໃນ stack ເຕັກໂນໂລຢີຂອງ Google, ພວກເຮົາເລືອກ HTTP Rest. ຄໍາອະທິບາຍກ່ຽວກັບສັນຍາ HTTP REST ມັກຈະຖືກອະທິບາຍຢູ່ໃນຫນຶ່ງໃນສອງຮູບແບບ: RAML ແລະ OAS, ເຊິ່ງໃນເມື່ອກ່ອນເອີ້ນວ່າ Swagger. ດັ່ງນັ້ນ, ທີມງານພັດທະນາທຸກຄົນຕ້ອງປະເຊີນຫນ້າກັບຄວາມຕ້ອງການທີ່ຈະເລືອກເອົາຫນຶ່ງໃນມາດຕະຖານ. ແຕ່ຍ້ອນວ່າມັນຫັນອອກ, ການເລືອກນີ້ສາມາດມີຄວາມຫຍຸ້ງຍາກຫຼາຍ.

ເປັນຫຍັງຕ້ອງມີຄຳອະທິບາຍປະກອບ?

ຄໍາບັນຍາຍແມ່ນຈໍາເປັນເພື່ອໃຫ້ຜູ້ໃຊ້ພາຍນອກສາມາດຊອກຫາສິ່ງທີ່ສາມາດເຮັດໄດ້ກັບການບໍລິການຂອງທ່ານໂດຍຜ່ານການໂຕ້ຕອບ HTTP ຂອງມັນໄດ້ຢ່າງງ່າຍດາຍ. ນັ້ນແມ່ນ, ໃນລະດັບພື້ນຖານ, ຄໍາບັນຍາຍຕ້ອງມີຢ່າງຫນ້ອຍບັນຊີລາຍຊື່ຂອງຊັບພະຍາກອນທີ່ມີຢູ່, ວິທີການ HTTP ຂອງພວກເຂົາ, ອົງການຈັດຕັ້ງການຮ້ອງຂໍ, ບັນຊີລາຍຊື່ຂອງຕົວກໍານົດການ, ຕົວຊີ້ວັດຂອງຫົວຂໍ້ທີ່ຕ້ອງການແລະສະຫນັບສະຫນູນ, ເຊັ່ນດຽວກັນກັບລະຫັດກັບຄືນແລະຮູບແບບການຕອບສະຫນອງ. ອົງປະກອບທີ່ສໍາຄັນທີ່ສຸດຂອງຄໍາບັນຍາຍສັນຍາແມ່ນຄໍາອະທິບາຍຄໍາເວົ້າຂອງພວກເຂົາ ("ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານເພີ່ມພາລາມິເຕີການສອບຖາມນີ້ໃສ່ຄໍາຮ້ອງຂໍ?", "ໃນກໍລະນີໃດກໍ່ຕາມລະຫັດ 400 ຈະຖືກສົ່ງຄືນ?")

ຢ່າງໃດກໍຕາມ, ໃນເວລາທີ່ມັນມາກັບການພັດທະນາຈໍານວນຫລາຍຂອງ microservices, ທ່ານຕ້ອງການສະກັດມູນຄ່າເພີ່ມເຕີມຈາກຄໍາອະທິບາຍລາຍລັກອັກສອນ. ສໍາລັບຕົວຢ່າງ, ອີງໃສ່ RAML / Swagger, ທ່ານສາມາດສ້າງລະຫັດລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍໃນຈໍານວນຫລາຍພາສາການຂຽນໂປຼແກຼມ. ນອກນັ້ນທ່ານຍັງສາມາດໄດ້ຮັບເອກະສານສໍາລັບ microservice ອັດຕະໂນມັດແລະອັບໂຫລດມັນໃສ່ developer-portal ຂອງທ່ານ :).

ຕົວຢ່າງຂອງຄໍາອະທິບາຍສັນຍາທີ່ມີໂຄງສ້າງ

ຫນ້ອຍທົ່ວໄປແມ່ນການປະຕິບັດການທົດສອບ microservices ໂດຍອີງໃສ່ຄໍາອະທິບາຍສັນຍາ. ຖ້າທ່ານໄດ້ຂຽນທັງຄໍາບັນຍາຍແລະອົງປະກອບ, ຫຼັງຈາກນັ້ນທ່ານສາມາດສ້າງ autotest ທີ່ກວດເບິ່ງຄວາມພຽງພໍຂອງການບໍລິການດ້ວຍຂໍ້ມູນປະເພດຕ່າງໆ. ບໍລິການສົ່ງຄືນລະຫັດຕອບໂຕ້ທີ່ບໍ່ໄດ້ອະທິບາຍໄວ້ໃນຄໍາບັນຍາຍບໍ? ມັນຈະສາມາດປະມວນຜົນຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງຢ່າງຊັດເຈນບໍ?

ຍິ່ງໄປກວ່ານັ້ນ, ການປະຕິບັດທີ່ມີຄຸນນະພາບສູງບໍ່ພຽງແຕ່ສັນຍາຕົວເອງ, ແຕ່ຍັງເຄື່ອງມືສໍາລັບການເບິ່ງເຫັນຄໍາບັນຍາຍເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ການເຮັດວຽກກັບ microservice ງ່າຍດາຍ. ນັ້ນແມ່ນ, ຖ້າສະຖາປະນິກໄດ້ອະທິບາຍສັນຍາທີ່ມີຄຸນນະພາບ, ອີງໃສ່ມັນ, ຜູ້ອອກແບບແລະນັກພັດທະນາຈະປະຕິບັດການບໍລິການໃນຜະລິດຕະພັນອື່ນໆໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມ.

ເພື່ອເປີດໃຊ້ເຄື່ອງມືເພີ່ມເຕີມ, ທັງ RAML ແລະ OAS ມີຄວາມສາມາດໃນການເພີ່ມ metadata ທີ່ບໍ່ໄດ້ສະຫນອງໃຫ້ໂດຍມາດຕະຖານ (ຕົວຢ່າງ, ນີ້ແມ່ນວິທີທີ່ມັນຖືກເຮັດໃນ OAS).

ໂດຍທົ່ວໄປ, ຂອບເຂດສໍາລັບຄວາມຄິດສ້າງສັນໃນການນໍາໃຊ້ສັນຍາສໍາລັບ microservices ແມ່ນຂະຫນາດໃຫຍ່ ... ຢ່າງຫນ້ອຍໃນທິດສະດີ.

ການປຽບທຽບ hedgehog ກັບງູ

ປະຈຸບັນ, ເຂດພັດທະນາບູລິມະສິດຢູ່ Acronis ແມ່ນການພັດທະນາຂອງເວທີ Acronis Cyber ​​​​. Acronis Cyber ​​​​Platform ແມ່ນຈຸດໃຫມ່ຂອງການເຊື່ອມໂຍງການບໍລິການຂອງພາກສ່ວນທີສາມກັບ Acronis Cyber ​​​​Cloud ແລະສ່ວນຕົວແທນ. ເຖິງແມ່ນວ່າພວກເຮົາມີຄວາມສຸກກັບ APIs ພາຍໃນຂອງພວກເຮົາທີ່ອະທິບາຍໄວ້ໃນ RAML, ຄວາມຕ້ອງການທີ່ຈະເຜີຍແຜ່ API ອີກເທື່ອຫນຶ່ງໄດ້ເຮັດໃຫ້ເກີດຄໍາຖາມທາງເລືອກ: ມາດຕະຖານຄໍາບັນຍາຍໃດທີ່ດີທີ່ສຸດທີ່ຈະໃຊ້ສໍາລັບວຽກງານຂອງພວກເຮົາ?

ໃນເບື້ອງຕົ້ນ, ມັນເບິ່ງຄືວ່າມີສອງການແກ້ໄຂ - ການພັດທະນາທົ່ວໄປທີ່ສຸດແມ່ນ RAML ແລະ Swagger (ຫຼື OAS). ແຕ່ໃນຄວາມເປັນຈິງມັນໄດ້ຫັນອອກວ່າມີຢ່າງຫນ້ອຍບໍ່ແມ່ນ 2 ທາງເລືອກ, ແຕ່ 3 ຫຼືຫຼາຍກວ່ານັ້ນ.

ໃນອີກດ້ານຫນຶ່ງມີ RAML - ເປັນພາສາທີ່ມີປະສິດທິພາບແລະມີປະສິດທິພາບ. ມັນປະຕິບັດລໍາດັບຊັ້ນແລະການສືບທອດໄດ້ດີ, ດັ່ງນັ້ນຮູບແບບນີ້ແມ່ນເຫມາະສົມສໍາລັບບໍລິສັດຂະຫນາດໃຫຍ່ທີ່ຕ້ອງການຄໍາອະທິບາຍຫຼາຍ - ນັ້ນແມ່ນ, ບໍ່ແມ່ນຜະລິດຕະພັນຫນຶ່ງ, ແຕ່ຫຼາຍ microservices ທີ່ມີສ່ວນທົ່ວໄປຂອງສັນຍາ - ລະບົບການກວດສອບ, ປະເພດຂໍ້ມູນດຽວກັນ, ຫນ່ວຍຄວາມຜິດ. .

ແຕ່ຜູ້ພັດທະນາ RAML, Mulesoft, ໄດ້ເຂົ້າຮ່ວມກຸ່ມ Open API, ເຊິ່ງກໍາລັງພັດທະນາ swagger. ດັ່ງນັ້ນ, RAML ຢຸດເຊົາການພັດທະນາຂອງມັນ. ເພື່ອຈິນຕະນາການຮູບແບບຂອງເຫດການ, ຈິນຕະນາການວ່າຜູ້ຮັກສາອົງປະກອບ Linux ຕົ້ນຕໍທີ່ປ່ອຍໃຫ້ເຮັດວຽກຢູ່ Microsoft. ສະຖານະການນີ້ສ້າງເງື່ອນໄຂເບື້ອງຕົ້ນສໍາລັບການນໍາໃຊ້ Swagger, ເຊິ່ງກໍາລັງພັດທະນາແບບເຄື່ອນໄຫວແລະຫລ້າສຸດ - ຮຸ່ນທີສາມ - ປະຕິບັດກັບ RAML ໃນຄວາມຍືດຫຍຸ່ນແລະການເຮັດວຽກ.

ຖ້າບໍ່ແມ່ນສໍາລັບສິ່ງຫນຶ່ງ ...

ດັ່ງທີ່ມັນປະກົດວ່າ, ບໍ່ແມ່ນທຸກສິ່ງອໍານວຍຄວາມສະດວກແຫຼ່ງເປີດໄດ້ຮັບການອັບເດດເປັນ OAS 3.0. ສໍາລັບການບໍລິການຈຸລະພາກໃນ Go, ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນການຂາດການປັບຕົວ go-swagger ສໍາລັບສະບັບຫລ້າສຸດຂອງມາດຕະຖານ. ຢ່າງໃດກໍຕາມ, ຄວາມແຕກຕ່າງລະຫວ່າງ Swagger 2 ແລະ Swagger 3 ແມ່ນ ໃຫຍ່. ສໍາລັບຕົວຢ່າງ, ໃນສະບັບທີສາມນັກພັດທະນາ:

• ປັບປຸງລາຍລະອຽດຂອງລະບົບການກວດສອບຄວາມຖືກຕ້ອງ
• ສໍາເລັດ ຮອງຮັບ JSON Schema
• ຍົກລະດັບຄວາມສາມາດໃນການເພີ່ມຕົວຢ່າງ

ສະຖານະການແມ່ນເປັນເລື່ອງຕະຫລົກ: ເມື່ອເລືອກມາດຕະຖານ, ທ່ານຈໍາເປັນຕ້ອງພິຈາລະນາ RAML, Swagger 2 ແລະ Swagger 3 ເປັນທາງເລືອກແຍກຕ່າງຫາກ. ຢ່າງໃດກໍຕາມ, ມີພຽງແຕ່ Swagger 2 ທີ່ມີການສະຫນັບສະຫນູນທີ່ດີສໍາລັບເຄື່ອງມື OpenSource. RAML ແມ່ນມີຄວາມຍືດຫຍຸ່ນຫຼາຍ ... ແລະສະລັບສັບຊ້ອນ, ແລະ Swagger 3 ໄດ້ຮັບການສະຫນັບສະຫນູນທີ່ບໍ່ດີຈາກຊຸມຊົນ, ດັ່ງນັ້ນທ່ານຈະຕ້ອງໃຊ້ເຄື່ອງມືທີ່ເປັນເຈົ້າຂອງຫຼືການແກ້ໄຂທາງການຄ້າ, ເຊິ່ງມີແນວໂນ້ມທີ່ຈະມີລາຄາແພງຫຼາຍ.

ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າມີລັກສະນະທີ່ສວຍງາມຫຼາຍໃນ Swagger, ເຊັ່ນ: ປະຕູທີ່ກຽມພ້ອມ editor.swagger.io, ທີ່ທ່ານສາມາດອັບໂຫລດຄໍາບັນຍາຍແລະໄດ້ຮັບການເບິ່ງເຫັນດ້ວຍຄໍາອະທິບາຍລາຍລະອຽດ, ການເຊື່ອມຕໍ່ແລະການເຊື່ອມຕໍ່, ຫຼັງຈາກນັ້ນສໍາລັບ RAML ພື້ນຖານແລະເປັນມິດຫນ້ອຍບໍ່ມີໂອກາດດັ່ງກ່າວ. ແມ່ນແລ້ວ, ທ່ານສາມາດຄົ້ນຫາບາງສິ່ງບາງຢ່າງໃນບັນດາໂຄງການໃນ GitHub, ຊອກຫາການປຽບທຽບຢູ່ທີ່ນັ້ນແລະນໍາໃຊ້ມັນຕົວທ່ານເອງ. ຢ່າງໃດກໍ່ຕາມ, ໃນກໍລະນີໃດກໍ່ຕາມ, ຜູ້ໃດຜູ້ຫນຶ່ງຈະຕ້ອງຮັກສາປະຕູ, ເຊິ່ງມັນບໍ່ສະດວກຫຼາຍສໍາລັບຄວາມຕ້ອງການພື້ນຖານຫຼືການທົດສອບ. ນອກຈາກນັ້ນ, swagger ແມ່ນ "ບໍ່ມີຫຼັກການ", ຫຼືເສລີຫຼາຍ - ມັນສາມາດຖືກສ້າງຂື້ນຈາກຄໍາຄິດຄໍາເຫັນໃນລະຫັດ, ເຊິ່ງ, ແນ່ນອນ, ກົງກັນຂ້າມກັບຫຼັກການທໍາອິດ API ແລະບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນຈາກອຸປະກອນ RAML ໃດໆ.

ໃນເວລາຫນຶ່ງພວກເຮົາໄດ້ເລີ່ມເຮັດວຽກກັບ RAML ເປັນພາສາທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍ, ແລະດັ່ງນັ້ນພວກເຮົາຕ້ອງເຮັດຫຼາຍຢ່າງດ້ວຍຕົນເອງ. ຕົວຢ່າງ, ຫນຶ່ງໃນໂຄງການໃຊ້ປະໂຫຍດ ການ​ໂຈມ​ຕີ ໃນການທົດສອບຫນ່ວຍ, ເຊິ່ງພຽງແຕ່ສະຫນັບສະຫນູນ RAML 0.8. ດັ່ງນັ້ນພວກເຮົາຕ້ອງເພີ່ມໄມ້ຄ້ອນເພື່ອວ່າຜົນປະໂຫຍດສາມາດ "ກິນ" RAML ຮຸ່ນ 1.0.

ທ່ານຈໍາເປັນຕ້ອງເລືອກບໍ?

ໂດຍໄດ້ເຮັດວຽກກ່ຽວກັບການສໍາເລັດລະບົບນິເວດຂອງການແກ້ໄຂສໍາລັບ RAML, ພວກເຮົາໄດ້ສະຫຼຸບວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ຽນ RAML ເປັນ Swagger 2 ແລະດໍາເນີນການທັງຫມົດອັດຕະໂນມັດ, ການກວດສອບ, ການທົດສອບແລະການເພີ່ມປະສິດທິພາບຕໍ່ໄປໃນມັນ. ນີ້ແມ່ນວິທີທີ່ດີທີ່ຈະໃຊ້ທັງຄວາມຍືດຫຍຸ່ນຂອງ RAML ແລະການສະຫນັບສະຫນູນເຄື່ອງມືຊຸມຊົນຈາກ Swagger.

ເພື່ອແກ້ໄຂບັນຫານີ້, ມີສອງເຄື່ອງມື OpenSource ທີ່ຄວນສະຫນອງການແປງສັນຍາ:

1. oas-raml-ແປງ ເປັນ​ປະ​ໂຫຍດ​ທີ່​ບໍ່​ໄດ້​ສະ​ຫນັບ​ສະ​ຫນູນ​ໃນ​ປັດ​ຈຸ​ບັນ​. ໃນຂະນະທີ່ເຮັດວຽກກັບມັນ, ພວກເຮົາຄົ້ນພົບວ່າມັນມີບັນຫາຈໍານວນຫນຶ່ງກັບ RAML ທີ່ສັບສົນທີ່ "ແຜ່ຂະຫຍາຍ" ຫຼາຍກວ່າໄຟລ໌ຈໍານວນຫລາຍ. ໂປຣແກຣມນີ້ຖືກຂຽນໄວ້ໃນ JavaScript ແລະປະຕິບັດການຂ້າມຄືນຂອງຕົ້ນໄມ້ syntax. ເນື່ອງຈາກການພິມແບບເຄື່ອນໄຫວ, ມັນກາຍເປັນເລື່ອງຍາກທີ່ຈະເຂົ້າໃຈລະຫັດນີ້, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຕັດສິນໃຈທີ່ຈະບໍ່ເສຍເວລາໃນການຂຽນ patches ສໍາລັບຜົນປະໂຫຍດທີ່ເສຍຊີວິດ.
2. webapi-parser - ເຄື່ອງມືຈາກບໍລິສັດດຽວກັນທີ່ອ້າງວ່າພ້ອມທີ່ຈະປ່ຽນທຸກຢ່າງແລະທຸກສິ່ງທຸກຢ່າງ, ແລະໃນທິດທາງໃດກໍ່ຕາມ. ມາຮອດປະຈຸບັນ, ການສະຫນັບສະຫນູນໄດ້ຖືກປະກາດສໍາລັບ RAML 0.8, RAML 1.0 ແລະ Swagger 2.0. ຢ່າງໃດກໍຕາມ, ໃນເວລາຂອງການຄົ້ນຄວ້າຂອງພວກເຮົາ, ຜົນປະໂຫຍດແມ່ນຍັງ ທີ່ສຸດ ປຽກ ແລະ ໃຊ້ບໍ່ໄດ້. ນັກພັດທະນາສ້າງປະເພດຂອງ IR, ໃຫ້ພວກເຂົາເພີ່ມມາດຕະຖານໃຫມ່ຢ່າງໄວວາໃນອະນາຄົດ. ແຕ່ມາເຖິງຕອນນັ້ນມັນບໍ່ເຮັດວຽກ.

ແລະນີ້ບໍ່ແມ່ນຄວາມຫຍຸ້ງຍາກທັງຫມົດທີ່ພວກເຮົາໄດ້ພົບ. ຫນຶ່ງໃນຂັ້ນຕອນໃນທໍ່ຂອງພວກເຮົາແມ່ນການກວດສອບວ່າ RAML ຈາກ repository ແມ່ນຖືກຕ້ອງທີ່ກ່ຽວຂ້ອງກັບຂໍ້ມູນສະເພາະ. ພວກເຮົາໄດ້ພະຍາຍາມໃຊ້ຫຼາຍອັນ. ເປັນເລື່ອງແປກທີ່, ພວກເຂົາທັງຫມົດໄດ້ສາບານຕໍ່ຄໍາບັນຍາຍຂອງພວກເຮົາໃນສະຖານທີ່ຕ່າງໆແລະດ້ວຍຄໍາທີ່ບໍ່ດີທີ່ແຕກຕ່າງກັນຫມົດ. ແລະບໍ່ສະເຫມີໄປເຖິງຈຸດ :).

ໃນທີ່ສຸດ, ພວກເຮົາໄດ້ຕົກລົງກັບໂຄງການທີ່ລ້າສະໄຫມໃນປັດຈຸບັນ, ເຊິ່ງຍັງມີບັນຫາຈໍານວນຫນຶ່ງ (ບາງຄັ້ງມັນຂັດຈາກສີຟ້າ, ມີບັນຫາໃນເວລາທີ່ເຮັດວຽກກັບການສະແດງອອກປົກກະຕິ). ດັ່ງນັ້ນ, ພວກເຮົາບໍ່ໄດ້ຊອກຫາວິທີທີ່ຈະແກ້ໄຂບັນຫາຂອງການກວດສອບຄວາມຖືກຕ້ອງແລະການປ່ຽນໃຈເຫລື້ອມໃສໂດຍອີງໃສ່ເຄື່ອງມືທີ່ບໍ່ເສຍຄ່າ, ແລະຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ຜົນປະໂຫຍດທາງການຄ້າ. ໃນອະນາຄົດ, ເມື່ອເຄື່ອງມື OpenSource ກາຍເປັນຜູ້ໃຫຍ່ຫຼາຍຂຶ້ນ, ບັນຫານີ້ອາດຈະແກ້ໄຂໄດ້ງ່າຍຂຶ້ນ. ໃນເວລານີ້, ຄ່າແຮງງານແລະເວລາສໍາລັບ "ການສໍາເລັດຮູບ" ເບິ່ງຄືວ່າພວກເຮົາມີຄວາມສໍາຄັນຫຼາຍກ່ວາຄ່າໃຊ້ຈ່າຍຂອງການບໍລິການທາງການຄ້າ.

ສະຫລຸບ

ຫຼັງຈາກທັງຫມົດນີ້, ພວກເຮົາຢາກແບ່ງປັນປະສົບການຂອງພວກເຮົາແລະສັງເກດວ່າກ່ອນທີ່ຈະເລືອກເຄື່ອງມືສໍາລັບການອະທິບາຍສັນຍາ, ທ່ານຈໍາເປັນຕ້ອງກໍານົດຢ່າງຊັດເຈນວ່າທ່ານຕ້ອງການຫຍັງຈາກມັນແລະງົບປະມານໃດທີ່ເຈົ້າເຕັມໃຈທີ່ຈະລົງທຶນ. ຖ້າພວກເຮົາລືມກ່ຽວກັບ OpenSource, ມີການບໍລິການແລະຜະລິດຕະພັນຈໍານວນຫລາຍທີ່ຈະຊ່ວຍໃຫ້ທ່ານກວດສອບ, ແປງ, ແລະກວດສອບຄວາມຖືກຕ້ອງ. ແຕ່ພວກມັນມີລາຄາແພງ, ແລະບາງຄັ້ງກໍ່ແພງຫຼາຍ. ສໍາລັບບໍລິສັດຂະຫນາດໃຫຍ່, ຄ່າໃຊ້ຈ່າຍດັ່ງກ່າວແມ່ນທົນທານໄດ້, ແຕ່ສໍາລັບການເລີ່ມຕົ້ນທີ່ເຂົາເຈົ້າສາມາດກາຍເປັນພາລະອັນໃຫຍ່ຫຼວງ.

ກໍານົດຊຸດເຄື່ອງມືທີ່ເຈົ້າຈະໃຊ້ໃນພາຍຫຼັງ. ຕົວຢ່າງ, ຖ້າທ່ານພຽງແຕ່ຕ້ອງການສະແດງສັນຍາ, ມັນຈະງ່າຍຕໍ່ການໃຊ້ Swagger 2, ທີ່ມີ API ທີ່ສວຍງາມ, ເພາະວ່າໃນ RAML ທ່ານຈະຕ້ອງສ້າງແລະຮັກສາການບໍລິການດ້ວຍຕົນເອງ.
ວຽກງານທີ່ເຈົ້າມີຫຼາຍຂຶ້ນ, ຄວາມຕ້ອງການເຄື່ອງມືຈະກວ້າງຂຶ້ນ, ແລະພວກມັນມີຄວາມແຕກຕ່າງກັນສໍາລັບເວທີທີ່ແຕກຕ່າງກັນ, ແລະມັນກໍ່ດີກວ່າທີ່ຈະເຮັດຄວາມຄຸ້ນເຄີຍກັບຮຸ່ນທີ່ມີຢູ່ເພື່ອໃຫ້ທາງເລືອກທີ່ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍຂອງທ່ານໃນອະນາຄົດ.

ແຕ່ມັນເປັນມູນຄ່າທີ່ຮັບຮູ້ວ່າລະບົບນິເວດທັງຫມົດທີ່ມີຢູ່ໃນທຸກມື້ນີ້ແມ່ນບໍ່ສົມບູນແບບ. ດັ່ງນັ້ນ, ຖ້າມີແຟນໃນບໍລິສັດທີ່ມັກເຮັດວຽກໃນ RAML ເພາະວ່າ "ມັນຊ່ວຍໃຫ້ທ່ານສະແດງຄວາມຄິດທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍ," ຫຼືໃນທາງກົງກັນຂ້າມ, ມັກ Swagger ເພາະວ່າ "ມັນຊັດເຈນກວ່າ," ມັນດີທີ່ສຸດທີ່ຈະປ່ອຍໃຫ້ພວກເຂົາເຮັດວຽກ. ໃນສິ່ງທີ່ເຂົາເຈົ້າມີ ພວກເຂົາເຈົ້າໄດ້ຖືກນໍາໃຊ້ເພື່ອມັນແລະຕ້ອງການມັນ, ເນື່ອງຈາກວ່າເຄື່ອງມືຂອງຮູບແບບໃດຫນຶ່ງຮຽກຮ້ອງໃຫ້ມີການດັດແກ້ທີ່ມີໄຟລ໌.

ສໍາລັບປະສົບການຂອງພວກເຮົາ, ໃນຂໍ້ຄວາມຕໍ່ໄປນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບການກວດສອບແບບຄົງທີ່ແລະແບບເຄື່ອນໄຫວທີ່ພວກເຮົາດໍາເນີນການໂດຍອີງໃສ່ສະຖາປັດຕະຍະກໍາ RAML-Swagger ຂອງພວກເຮົາ, ເຊັ່ນດຽວກັນກັບເອກະສານທີ່ພວກເຮົາສ້າງຈາກສັນຍາ, ແລະວິທີການເຮັດວຽກທັງຫມົດ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ເຈົ້າໃຊ້ພາສາຫຍັງເພື່ອອະທິບາຍສັນຍາບໍລິການຈຸລະພາກ?

• RAML 0.8

• RAML 1.0

• Swagger 2

• OAS3 (aka)

• ແຜນຜັງ

• ອື່ນໆ

• ບໍ່ໄດ້ໃຊ້

100 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 24 ຜູ້ໃຊ້ງົດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com