ในการออกแบบ API ในรายละเอียดเราจะมาดูว่าอะไรควรทำและอะไรไม่ควรทำ 

     (1) ไม่ควรมีพารามิเตอร์หลายตัวที่เป็นชนิดข้อมูลเดียวกัน : เพราะมันมีโอกาศที่จะวางข้อมูลสลับกันซึ่งอาจจะก่อให้เกิดข้อผิดพลาดได้ เช่น เมธอด addUsers(lastName:String, firstName:String, initial:String, userName:String, email:String) ซึ่งเป็นไปได้ที่อาจจะมีการสลับข้อมูลโดยเอาชื่อแรกมาก่อน ดังนั้นวิธีการที่แนะนำคือกำหนดชนิดข้อมูลที่เหมาะสมและให้ผู้ใช้ API สร้างเป็นออบเจกต์ขึ้นมาและใช้วิธีส่งผ่านออบเจกต์ ดังนั้นจะได้เป็นเมธอด addUser(user:User) ซึ่งไม่มีพารามิเตอร์มากมายและแม่นยำในการส่งข้อมูล 

     (2) ไม่ควรส่งข้อมูลกลับเป็นข้อมูลชนิดพื้นฐาน (primitive data type) : เช่น เราบอกว่า API จะส่งข้อมูลกลับเป็นข้อมูลชนิด String ประกอบด้วยข้อมูล lastname, firstname, initial, username, email ในรูปแบบตามที่เรากำหนด ซึ่งผู้ใช้ API จะต้องไปแยกแยะ (parsing) เพื่อใช้งานเอง ความซับซ้อนและไม่ยืดหยุ่นของการทำแบบนี้คือ ในกรณีที่ข้อมูลบางอย่างไม่มี เราจัดการอย่างไร รูปแบบของข้อมูลจะเป็นอย่างไร หรือหากเราต้องการเพิ่มข้อมูลในภายหลังจะส่งผลกระทบมากมาย แต่หากเราส่งข้อมูลกลับเป็นชนิดข้อมูลที่เหมาะสม ผู้ใช้ API จะได้ผลลัพธ์กลับเป็นออบเจกต์ซึ่งข้อมูลที่ต้องการจะอยู่ในแต่ละฟิลด์อย่างชัดเจน และในกรณีที่เราต้องการเพิ่มข้อมูล เราสามารถเพิ่มฟิลด์ได้โดยไม่มีผลกระทบกับผู้ใช้ API และการแก้ไขเอกสารประกอบก็ง่ายเพราะเพียงแค่ระบุฟิลด์ใหม่เพิ่มเติมเท่านั้น ตัวอย่างเช่น แทนที่จะเป็นเมธอด getUserData():String ก็จะเป็น getUserData():User

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

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

     (5) สำเนาของออบเจกต์ที่ส่งกลับไปให้ผู้ใช้ API จะต้องไม่ได้รับผลกระทบจากการแก้ไขออบเจกต์ใน API และการกระทำใดๆกับออบเจกต์ที่ผู้ใช้ API ได้รับไปจะไม่ส่งผลกระทบต่อการทำงานภายในของ API กล่าวคือออบเกจต์ที่ส่งไปจะต้องแก้ไขไม่ได้ (immutable object) การกระทำใดๆกับออบเจตก์ไม่ว่าจากฝั่งใดจะต้องไม่กระทบอีกฝั่งหนึ่ง ซึ่งเป็นการแยกส่วนระหว่างผู้ให้บริการ API และผู้ใช้ API ออกจากกัน 

     (6) กำหนดให้ส่วนของโปรแกรมที่เราไม่ต้องการให้ถูกเข้าถึงและใช้งานจากภายนอกเป็น private และเฉพาะส่วนที่อนุญาติให้ใช้หรือเผยแพร่จึงจะเป็น public เพราะผู้ใช้ API ต้องเข้ามาสำรวจ API ที่เขาจะใช้อยู่แล้ว และถ้าเราเปิดเผยส่วนหนึ่งส่วนใดที่ไม่จำเป็นให้ผู้ใช้ API เห็น จะเกิดความพยายามในการใช้งานถึงแม้ว่าเราจะไม่ต้องการให้ใช้หรือไม่มีเอกสารประกอบก็ตาม