# Overview # Key Considerations There are many available protocols that can be used when designing an API. They are summarized in the table below. | Protocol | Description | Pros | Cons | Use Cases | | ------------------------------------------ | --------------------- | ----------------- | ----------------- | ---------------------- | | REpresentational State Transfer ([[REST]]) | ![[REST#Overview]] | ![[REST#Pros]] | ![[REST#Cons]] | ![[REST#Use Cases]] | | [[GraphQL]] | ![[GraphQL#Overview]] | ![[GraphQL#Pros]] | ![[GraphQL#Cons]] | ![[GraphQL#Use Cases]] | | Remote Procedure Call ([[Remote Procedure Calls (RPC)]]) | ![[Remote Procedure Calls (RPC)#Overview]] | ![[Remote Procedure Calls (RPC)#Pros]] | ![[Remote Procedure Calls (RPC)#Cons]] | ![[Remote Procedure Calls (RPC)#Use Cases]] | | [[SOAP]] | ![[SOAP#Overview]] | ![[SOAP#Pros]] | ![[SOAP#Cons]] | ![[SOAP#Use Cases]] | | [[WebSockets]] | | | | | | [[MQTT]] | | | | | | | | | | | | | | | | | # Implementation Details - URL - Header / Body ## Performance Options for APIs #flashcard - [[Pagination]] - Load More - Infinite Scrolling <!--ID: 1751507777162--> ## Versioning ### URL Versioning `/v1/events` vs. `/v2/events` ### Header Versioning Puts the version in an HTTP header instead: `Accept-Version: v2` or `API-Version: 2`. This keeps URLs cleaner and follows HTTP standards better, but it's less obvious to developers and harder to test in browsers. ## [[Authentication]] and [[Authorization]] Options for authentication and authorization in APIs include... #flashcard - [[API Keys]] - [[JSON Web Token (JWT)]] - [[Role-based Access Control (RBAC)]] <!--ID: 1753886610277--> # Useful Links - Stripe APIs #ReadLater # Related Topics - Internet of Things ([[IoT]]) - [[API Gateway]] - [[Postman]]