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

     พื้นฐานในการออกแบบ API ให้มีความสะดวกในการใช้งาน มี 4 หัวข้อ คือ (1) การเข้าถึงได้ง่ายและใช้งานได้ง่าย (visibility) : โดยผู้ใช้งานสามารถทำความเข้าใจได้อย่างง่ายๆว่า API ทำอะไรได้บ้าง API ที่มีการใช้งานมากจะต้องโดดเด่นและเข้าถึงได้ง่าย ลดโอกาสที่จะเกิดการใช้งานผิดพลาด เช่น ในการเรียงลำดับรายการตามสถานะที่ต้องการควรใช้ enum แทนที่จะใช้ข้อความตามที่เก็บในฟิลด์จริงๆ ตัวอย่างเช่น เมธอด sort(status.KEY) (2) การคำนึงถึงการนำใช้งาน (model) : เราต้องเข้าใจถึงรูปแบบในการนำไปใช้งานเพื่อที่จะออกแบบภาพรวม (abstraction) ที่หมาะสมแก่การนำไปใช้เพื่อให้งานสำเร็จ เช่น ตั้งชื่อเมธอดให้สอดคล้องกับสิ่งที่ API ทำ ตัวอย่างเช่น ในการดึงข้อมูลสินค้าเมธอด getProduct(productID:String) จะชัดเจนกว่าเมธอด get(productID:String) หรือถ้าผู้ใช้งาน API เป็นคลังสินค้าขนาดใหญ่เราอาจจะมีเมธอด getLackNo(lack:number) เมธอด getShelfNo(shelf:number) และเมธอด getBlockNo(block:numbe) เพื่อให้สามารถนำไปใช้ได้ (3) การกำหนดชนิดข้อมูลที่สอดคล้องกับการนำไปใช้งาน (mapping) : การส่งข้อมูลกลับไปให้ผู้ใช้งานเป็นอีกเรื่องที่สำคัญ การส่งข้อมูลที่ครบถ้วนกลับในรูปแบบออบเจกต์จะช่วยให้ผู้ใช้งาน API นำไปใช้ได้ง่ายกว่า โดยเราจัดเตรียมเอกสารอธิบายฟิลด์ต่างๆให้ชัดเจนซึ่งผู้ใช้งาน API สามารถนำไปประยุกต์ใช้งานเองได้ (4) การตอบกลับผู้ใช้ทั้งในกรณีที่ใช้งานถูกต้องและไม่ถูกต้อง (feedback) : ในกรณีที่ใช้งานถูกต้องผู้ใช้งาน API ย่อมได้ผลลัพธ์กลับไปตามต้องการ แต่ในกรณีที่ใช้งานไม่ถูกต้อง ผู้ใช้อาจจะได้รับข้อมูลที่ไม่ถูกต้องกลับไป เช่น เมธอด sortBy(stt:String) หากพารามิเตอร์ที่ส่งเขามาไม่ถูกต้องอาจจะได้ข้อมูลแบบไม่เรียงลำดับกลับไปหรืออาจจะไม่ได้ข้อมูลอะไรกลับไปเลยก็ได้ ดังนั้นเราควรปรับปรุง API ให้ตรวจสอบพารามิเตอร์และแจ้งข้อผิดพลาดกลับไปแทนที่จะปล่อยให้ส่งข้อมูลที่ไม่ถูกต้องตามวัตถุประสงค์ของ API กลับไป

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