[Class Report] System Development (Year 3) — Week 44

Integrating API Connections into Use Cases: Turning External Data into “Useful Features”

In Week 44, we took the API calls we implemented last week and embedded them into concrete use cases for our app.
The theme was moving beyond “it works” and making it a meaningful feature for users.

■ Teacher’s Introduction: “APIs are ingredients. They only gain value when you cook them.”

Mr. Tanaka: “Data you can get from an API is often hard to use as-is.
Today, you’ll design when, where, and how to use it, and translate it into the user experience.”

He also reviewed common API-integration pitfalls:

• stopping at just displaying data
• calling the API every time and making the app slow
• breaking the screen when errors occur

This reinforced the importance of design.

■ Today’s Goals

1. Naturally integrate API data into existing use cases
2. Perform processing, decision-making, and caching in the Service layer
3. Ensure the use case still works even when the API fails
4. Design user-friendly displays and messages

■ Exercise ①: Clarify the Use Case Where the API Will Be Used

Each group first clarified which use case would use an API.

Examples

• Library system
  • Search for a book → use a Weather API to show a “rainy-day return deadline reminder”
• School event management
  • Event list → use a Map API to display the location
• Learning support app
  • English input → use a Translation API to show Japanese support text

Student A: “If you don’t make the API the ‘main character,’ the app feels more natural.”

■ Exercise ②: “Process” API Data in the Service Layer

Instead of passing raw API responses directly to the UI, we formatted the data into the needed shape in the Service layer.

Example: Weather API Service (Conceptual)

def get_weather_hint(self, city):
    weather = self.weather_api.fetch(city)

    if weather["condition"] == "Rain":
        return "Rain is forecast today. Please be mindful of the return deadline."
    else:
        return None

Key points:

• The UI only decides whether to display something or not
• API spec changes don’t directly affect the UI
• Data is interpreted in the context of the use case

Student B: “It feels like we’re turning raw API data into a meaningful message.”

■ Exercise ③: Reducing Calls with Caching

APIs are assumed to be:

• slow
• rate-limited

So we introduced a simple cache.

Learning-oriented image

• Reuse the same city’s weather for 10 minutes
• Manage caching in the Service layer
• Confirm API call counts via logs

Student C: “After adding caching, it felt faster right away!”

Mr. Tanaka also shared a practical point:
“Caching is a trade-off between accuracy and speed.”

■ Exercise ④: Don’t Stop the Use Case When the API Fails

Next, we designed behavior for when the API is unavailable.

Implementation policy

• Even if the API fails, the core function continues
• Only supplemental info (weather/translation, etc.) is hidden
• Show a short, simple notice to users

try:
    hint = weather_service.get_weather_hint(city)
except Exception:
    hint = None

UI display example:

• “Weather information is currently unavailable.”

Student D: “Using APIs for ‘nice-to-have’ features is safer.”

■ Exercise ⑤: Integrate into the UI and Adjust Display

Finally, we blended API-derived information naturally into the UI.

• Keep it as supportive info, not too prominent
• Adjust “importance” through color and placement
• Keep error messages subtle

Student E: “Even if the app uses APIs, ideally users don’t have to notice.”

■ Whole-Class Sharing: What Worked Well

Examples of successful approaches shared in class:

• Turning API results into sentences to improve UX
• Stable behavior through caching + fallback
• Centralizing API-related decisions in the Service layer
• Tracking API failure rates through logs

■ Teacher’s Closing Comment

“The goal of API integration is not using an API—
it’s improving the user experience.

Designing:

• where to use it, and
• what to do when it isn’t available,
  is exactly what real-world work looks like.”

■ Homework (For Next Week)

1. Create a one-page use-case description that includes the API
2. Prepare screen captures for both API success and API failure cases
3. If you were to add one more API, propose where you would integrate it

■ Next Week Preview: Multiple APIs and the Idea of Asynchrony

Next week, we will learn:

• design considerations when using multiple APIs at the same time, and
• how to handle waiting time and failures—core thinking for asynchronous processing

Week 44 marked the shift of API integration from a “tech demo” into a “practical feature.”
Students steadily built the skills to use external services smartly and safely through good design.