เหตุใดจึงไม่มี WSDL type ที่รองรับ Web Api

ดังนั้นฉันเพิ่งเริ่มต้นกับ. Net WebApi และสิ่งหนึ่งที่ฉันสังเกตเห็นได้ทันทีคือไม่มีสัญญาที่กำหนดว่า API มีลักษณะอย่างไรและควรใช้งานอย่างไร (คำขอ / ตอบจากแต่ละการกระทำ) ซึ่งมักจะอยู่ในรูปแบบของ WSDL สำหรับ WCF / Soap

ดูเหมือนว่าฉันจะเป็นสิ่งที่มีค่ามากและทำให้ชีวิตง่ายขึ้นสำหรับผู้บริโภค API ของคุณ

มีเหตุผลที่ไม่มีหรือไม่ มีกระบวนทัศน์การเขียนโปรแกรมหรือหลักการที่ฉันไม่ทราบหรือไม่? มีวิธีที่ฉันสามารถสร้างหรือไม่

สบู่, ที่เหลือและความคิดสร้างสรรค์ของคน

SOAP ต้องการเอกสารคำอธิบายเช่น WSDL เนื่องจากทรัพยากรแต่ละรายการสามารถใช้กับข้อความที่แตกต่างกันได้ไม่มีคำจำกัดความเกี่ยวกับโปรโตคอลเกี่ยวกับข้อ จำกัด ของชื่อ / ข้อความที่เป็นไปได้ที่คุณสามารถจัดการทรัพยากรได้

ตัวอย่างเช่นใน SOAP บริการเว็บของคุณที่อนุญาตให้ลูกค้าจัดการผู้ใช้สามารถเปิดเผยการดำเนินการที่สร้างผู้ใช้ในข้อความต่าง ๆ มากมายเช่น:

addUser
createUser
insertUser

แน่นอนว่าข้อความเหล่านี้เป็นเพียงตัวอย่างเล็กน้อยเพราะฉันเห็นชื่อวิธีการบริการบนเว็บที่ตลกมากมาย มีคนที่สร้างสรรค์จริงๆที่นั่น

ในทางกลับกันหากคุณเปิดเผยระบบพื้นฐานของคุณโดยใช้ web api ที่เคารพหลักการ REST อย่างแท้จริงลูกค้าเพียงแค่ต้องรู้ว่าคุณมีทรัพยากรชื่อผู้ใช้เนื่องจากมีโอกาส 99% ที่คุณสามารถสร้างผู้ใช้ในสิ่งนี้ ทาง

POST /Users

และสิ่งนี้เกิดขึ้นสำหรับแต่ละการดำเนินการที่คุณต้องการเปิดเผยโดยใช้ SOAP หรือ web api REST

แม้จะเป็น SOAP โปรโตคอลซึ่ง จำกัด สิ่งที่คุณสามารถหรือไม่สามารถทำได้และเป็น REST สถาปัตยกรรมสไตล์ซึ่งทำให้มีจุดเปิดมากมายในการทำสิ่งต่าง ๆ มีความพยายามในการกำหนดการประชุมว่าจะเปิดเผยและใช้เว็บ REST ของ REST อย่างไร

คำอธิบายส่วนที่เหลือของเว็บ API

ในด้านของวิธีการอธิบาย REST API เว็บที่ผมสามารถยกวางท่า ไม่ใช่ความพยายามในการสร้าง WSDL เช่น web api REST แต่เป็นการพยายามสร้างมาตรฐานแบบเปิดสำหรับอธิบาย web apis REST

Swagger เป็นข้อมูลจำเพาะและกรอบการใช้งานที่สมบูรณ์สำหรับการอธิบายการผลิตการบริโภคและการแสดงผลเว็บเซอร์วิส RESTful

ฉันใช้ Swagger เป็นอย่างมากและรักมันเป็นอย่างมากส่วนใหญ่เป็นเพราะSwagger UIที่ให้คุณสร้างไลฟ์คอนโซลและเอกสารสำหรับเว็บ API ของคุณ

มีการใช้งาน Swagger สำหรับภาษาส่วนใหญ่: C #, Java, Python, Ruby และอื่น ๆ

หากคุณใช้ ASP .NET Web API มีโครงการบางอย่างที่สร้างสเปค Swagger โดยอัตโนมัติเช่นSwagger.NET

สร้างลูกค้าให้กับส่วนที่เหลือของเว็บ API

เนื่องจากข้อ จำกัด ของ REST เช่นชุดคำกริยาที่ จำกัด (GET, POST, PUT, DELETE และอื่น ๆ ) จึงไม่สามารถแพร่กระจายเพื่อสร้างไลบรารี่ของไคลเอ็นต์ให้กับ web api REST

โครงการเช่นWebApiProxyสามารถสร้างลูกค้าได้อย่างง่ายดายด้วย C # และ Javascript

อนุสัญญาสำหรับส่วนที่เหลือของเว็บ API

เพื่อให้สิ่งมีชีวิตของเราในฐานะนักพัฒนาง่ายขึ้นเป็นสิ่งที่ดีกำหนดระเบียบบางส่วนของวิธีการ api REST เว็บของเราจะทำงานความพยายามที่ดีที่สุดที่ฉันรู้ในสาขานี้คือApigee - ebook ของ Web Api Design ที่ดี e-book ไม่ใช่ความพยายามในการสร้างพระคัมภีร์หรือมนต์เกี่ยวกับวิธีการออกแบบ API ของคุณ แต่เป็นชุดของข้อตกลงที่พบในเว็บ REST apis ขนาดใหญ่เช่น Twitter, Facebook, Linkedin, Google ฯลฯ

โดยสรุปเนื่องจาก SOAP ได้รับการออกแบบให้อธิบายตัวเอง: จุดสิ้นสุด SOAP มักจะประกอบด้วย wsdl ที่อธิบายการดำเนินงานที่ให้บริการและลักษณะของข้อมูล (โดยใช้ XSD แบบฝัง) ที่แต่ละการดำเนินการใช้และ / หรือส่งคืน
เนื่องจากการอธิบายตนเองนี้จึงเป็นไปได้สำหรับแอปพลิเคชันเช่น Visual Studio เพื่อสร้างพร็อกซีเว็บเซอร์สำหรับมัน

นอกจากนี้ยังมีส่วนขยายจำนวนมากสำหรับ SOAP (ข้อกำหนด WS- *) ที่อนุญาตให้ใช้การเข้ารหัสหรือพฤติกรรมการทำธุรกรรมกับ SOAP แนวคิดคือคุณสามารถใช้ SOAP เป็นร้านค้าครบวงจรในการสร้างบริการเว็บระดับองค์กร

ในทางกลับกัน...

WebAPI ออกแบบมาเพื่อให้บริการ REST รูปแบบการสื่อสารสำหรับ REST มักจะเป็น JSON หรือ xml ธรรมดา - แม้ว่ามันจะไม่สำคัญก็ตาม แต่ก็อาจเป็นข้อความธรรมดาได้ บริการ REST ปฏิบัติตามปรัชญาที่แตกต่างกันโดยสิ้นเชิง: พวกเขามีน้ำหนักเบาเพื่อให้สามารถใช้งานได้ง่ายโดยสคริปต์ฝั่งไคลเอ็นต์ซึ่งเป็นส่วนหนึ่งของโซลูชัน AJAX หรืออุปกรณ์มือถือ
ดังนั้นจึงมีความจำเป็นที่จะต้องรักษาระดับของงานให้น้อยที่สุดรวมถึงการอธิบายตัวเอง นอกจากนี้แม้ว่าคุณต้องการรูปแบบการสื่อสารส่วนใหญ่ที่ใช้ในบริการ REST (เช่น JSON) จะไม่มีวิธีที่เป็นทางการในการอธิบายเนื้อหาของพวกเขา

โดยสรุปคุณสามารถพูดได้ว่าเว็บเซอร์วิส SOAP มักจะใช้เพื่อรวมโซลูชัน (อาจแตกต่างกัน) ในขณะที่บริการ REST เหมาะสำหรับการสื่อสารระหว่างส่วนต่าง ๆ ของโซลูชันเดียวกัน

SOAP / WS- * และ RESTful API ไม่เหมือนกัน หากคุณต้องการสร้าง SOAP / WS- * WSDL ที่รองรับ APIs เครื่องมือที่เลือกใน Microsoft stack คือ WCF ซึ่งประกอบเข้ากับตัวเลือก HTTP binding (มีตัวเลือกการเชื่อมโยง XML และ JSON, XML เป็นตัวเลือกการสนับสนุน WSDL)

ในทางปฏิบัติการใช้ WSDL จากภาษาหรือแพลตฟอร์มการใช้งานที่แตกต่างกันนั้นเป็นปัญหา WS- * เลเยอร์ความปลอดภัยเหนือระดับสูงสุด

ประสบการณ์ของตัวเองส่วนใหญ่จะเป็น. Net, Node, Java และ PHP ในเรื่องนี้และฉันสามารถพูดได้ว่าเมื่อคุณมีแพลตฟอร์มที่ไม่จำเป็นต้องกำหนดรายละเอียดของประเภทลูกหรือจะใช้ "Object" เป็น คำจำกัดความมันเป็นปัญหาที่จะพูดน้อย นอกเหนือจากนี้ส่วนใหญ่ไม่มีใครเข้าใจ SOAP / WS- * ทั้งหมดที่ต้องใช้เครื่องมือในการทำงาน เครื่องมือนี้มีค่าใช้จ่ายจำนวนมากและระบบที่แตกต่างกันทำงานแตกต่างกัน

นี่คือเหตุผลบางอย่างที่ผู้คนพยายามใช้งานที่ง่าย บริการ REST (ala Web API) เสนอจุดสิ้นสุดรอบวัตถุ / รัฐ แนวคิดที่จะง่ายกว่าในการกำหนดชุดของโครงสร้างวัตถุที่ง่ายกว่าที่แสดงในรูปแบบ JSON และจุดสิ้นสุดที่จะใช้กับโครงสร้างเหล่านี้มากกว่าที่จะพยายามใช้ WSDL จากสภาพแวดล้อมต่างดาวที่ไม่ทำงานจากนั้นลองขุดและ หลีกเลี่ยงปัญหา

กระแทกแดกดันนี้เป็นหนึ่งในพื้นที่ที่ผมเคยใช้โหนดในจำนวนมากเป็นบริการแปลเพียงเพราะมันก็มากพอที่มีความยืดหยุ่นที่จะยอมรับการใช้งานที่สกปรกเป็นลูกค้าและฉันสามารถเขียนลูกค้าที่เรียบง่ายกับน้ำหนักบรรทุกดัดแปลงของฉันที่ทำงานได้ดี EX: C # ได้รับข้อความ JSON ที่ฉันใช้ JSON.Net เพื่อแปลงเป็นการแสดงวัตถุที่ฉันกำหนดใช้งานได้จริงเมื่อฉันไม่สามารถใช้การนำเข้า WSDL ได้

ในทางปฏิบัติสิ่งนี้เกิดขึ้นมากมาย

ในขณะที่คำตอบมากมายที่นี่ยอดเยี่ยมฉันคิดว่าคำตอบนั้นง่ายกว่ามาก: คุณกำลังมองหาเทคโนโลยีที่ผิดสำหรับงาน

หากคุณต้องการสร้างบริการ SOAP คุณควรยึดถือกับ WCF เป็นอย่างยิ่ง มันยังคงเป็นกรอบที่มีประสิทธิภาพมาก Microsoft ยังคงพัฒนาอย่างแข็งขันไม่มีการประกาศเพื่อให้เราคิดว่ามันจะเกิดขึ้นที่ใดก็ได้ในอนาคต Web API ไม่ได้แทนที่ WCF แต่อย่างใด (แม้ว่าอาจจะเป็นเทรนด์ที่ดีกว่า WCF)

Web API เคยเป็นส่วนหนึ่งของ WCF แต่มันถูกย้ายไปยังตระกูล ASP.NET เพราะมันไม่ตรงกับเทคโนโลยี WCF อื่น ๆ Web API เกี่ยวข้องกับการใช้ HTTP เป็นโปรโตคอลแอปพลิเคชันมากกว่าโปรโตคอลการถ่ายโอน ใน Web API นั้นคำกริยา HTTP เป็นราชาใน WCF HTTP เป็นเพียงการให้บริการเพื่อเปิดใช้งานโปรโตคอล SOAP

อย่าโทษ Web API เนื่องจากไม่ให้ความสามารถในการทำสิ่งที่ไม่ได้ทำ