Application Programming Interfaces (APIs)

• Application Programming Interfaces (APIs) specify components in terms of operations, inputs, and outputs, independent of implementation.
• APIs allow implementation flexibility without affecting users and define programmatic system boundaries.
• Programmers design, develop, and test APIs, thus API thinking enhances code quality.

Dropbox API Example

• The Dropbox API /download version 1 downloads a file from a user’s Dropbox.
• The URL is https://content.dropboxapi.com/2/files/download.
• Authentication requires user authentication and Dropbox-API-Select-Admin.
• The endpoint for downloads is Content-download.
• The required scope is files.content.read.
• The parameters for a download include the path, such as {"path": "/Homework/math/Prime_Numbers.txt"}.

Characteristics of a Good API

• An ideal API is easy to use, even without documentation, and hard to misuse.
• Readable and maintainable code supports a good API.
• A good API is powerful enough to meet requirements, easy to evolve, and appropriate for its audience.

Representational State Transfer (REST)

• REST is an architectural style for web standards, facilitating system communication through RESTful APIs.
• RESTful APIs are stateless, thus servers do not maintain state between requests improving scalability.

Other Protocols

• SOAP is XML-based, making it less human-readable and harder to write manually.
• GraphQL is a query language for APIs, allowing for custom data definitions.

REST Fundamentals

• Resources are accessed via URIs (Uniform Resource Identifiers).
• REST operates over HTTP (application layer protocol).
• HTTP is utilized for clear, universal resource manipulation in REST.

Hypertext Transfer Protocol (HTTP)

• HTTP is an application layer protocol for networking that uses CRUD operations.
• PUT is used to create or update data on a server.
• GET is used to retrieve information from a server.
• POST sends data to the server, often to update information.
• DELETE is used to remove information from a server.
• GET is considered a safe operation because it should not change the resource.
• PUT and DELETE are idempotent, meaning repeated calls have the same effect as a single call.
• POST is non-idempotent, as repeated calls can change the state, like placing multiple orders.

HTTP Format

• An HTTP request consists of a verb (e.g., GET), URI, HTTP Version, Header, and Body.
• An HTTP response includes the HTTP Version, Response Code, Header, and Body.
• The standardized format of HTTP simplifies its adoption.

Data Representation

• Data is commonly represented in JSON or XML formats.
• Representations can include complete resource data or sub-resources for partial data.
• Smaller representations can improve transfer speed.

HTTP Status Codes

• 200 (OK) indicates success.
• 201 (Created) confirms the resource was created.
• 202 (Accepted) means the request was accepted for processing.
• 204 (No Content) signals that the server successfully processed the request but is not returning any content.
• 205 (Reset Content) tells the client to reset the document view.
• 301 (Moved Permanently) indicates redirection.
• 400 (Bad Request) reports an issue with the request.
• 401 (Unauthorized) means authentication is required.
• 404 (Not Found) indicates the resource was not found.

VehicleVault Web Store Example

• VehicleVault's goals include getting a parts list, retrieving part details, and submitting purchase orders (PO).
• The RESTful design for listing parts uses GET http://www.vehiclevault.com/parts.
• Part details are accessed using GET http://www.vehiclevault.com/parts/00345.
• REST’s stateless nature enhances scalability and availability but can impact performance due to multiple requests.

API Design Principles

• Well-structured URIs should not contain spaces (use _ or - instead), be case-insensitive, and avoid verbs unless the resource is an operation.
• Reusable APIs follow common patterns.
• Modular APIs split features for security.

Documenting APIs

• Tools like Swagger are used for complex documentation. Simpler docs include parameters, functionality, and examples.
• API documentation should include the description, HTTP method, results, and intended users.

Prototyping: Online Shopping System (Python)

• A basic shopping system can be prototyped in Python without a database.
• Key features include mock login, adding/removing cart items, and displaying the total.
• The structure involves main.py (entry point), user.py (login logic), cart.py (cart operations), and products.py (hardcoded data).

Software Quality Assurance (SQA)

• SQA measures characteristics such as correctness and maintainability.
• IEEE quality considers whether a system meets specified requirements and user/customer expectations.
• McCall’s Quality Model focuses on product revision, transition, and operation.

McCall’s Quality Model Factors

• Usability refers to the learning effort (e.g., training time).
• Integrity concerns access control (e.g., view-only permissions).
• Efficiency is about resource use (e.g., transactions/sec).
• Correctness is the fulfillment of specifications (e.g., defects/KLOC).
• Reliability refers to failure probability (e.g., MTBF).
• Maintainability is the effort required for fixes (e.g., MTTC).
• Testability involves logs and backups.
• Flexibility measures the effort for modifications.
• Reusability concerns the potential for reuse.
• Portability is the effort to transfer the system (e.g., target systems).
• Interoperability is the effort to achieve coupling (e.g., app integration).
• Compliance is verified through reviews, inspections, and testing.
• Prioritization is based on stakeholder needs since full verification is impossible.