REST规范下按关联资源ID获取资源的命名及天气服务设计疑问

Great questions! Let's tackle them one by one to make your RESTful service clean and maintainable:

1. GET Request URL Design #

Your initial idea api/v1/WeatherByCityId/{cityid} is technically functional, but we can tweak it to better align with RESTful best practices for clarity and consistency.

A more intuitive approach centers on resource hierarchy, since weather data is a sub-resource tied directly to a city. A strong, convention-friendly option is:

api/v1/cities/{cityId}/weather

This makes it immediately clear you're requesting weather data for a specific city, which follows REST's core principle of modeling endpoints after entities and their relationships.

If you want something slightly more concise while retaining clarity, you could also use:

api/v1/weather?cityId={cityId}

But the hierarchical version is generally preferred for REST services—it better reflects that weather data belongs to a city, making your API easier for other developers to understand at a glance.

Whichever you choose, stick to lowercase (a standard API convention) and use camelCase or kebab-case for path segments (e.g., city-id instead of cityid if you prefer kebab-case, though camelCase is widely adopted in API paths too).

2. Database Entity Design #

Since you're populating weather data hourly and will likely want to retain historical records (even if you only return the latest to clients), separating City and Weather entities is the far better choice over a single combined table. Here's why:

• Normalization & Reduced Redundancy: A City table (cities) stores static or rarely changing data like city ID, name, geographic coordinates, etc. The Weather table (weathers) stores time-series data: each row represents one hourly reading with fields like city_id (foreign key linking to cities), temperature, humidity, pressure, and a recorded_at timestamp. This avoids repeating city data in every weather entry, saving storage and making city info updates (if needed) trivial.
• Flexibility & Scalability: If you later add more city attributes (like population or timezone) or weather metrics (wind speed, precipitation), extending separate tables is straightforward. A combined table would quickly get cluttered and harder to maintain.
• Historical Data Queries: A separate Weather table makes it easy to pull historical data (e.g., "get all temperatures for city X in the last 7 days")—something a single table could handle, but with unnecessary data duplication that grows over time.

Example simplified table schemas:

-- cities table
CREATE TABLE cities (
    id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    latitude DECIMAL(9,6),
    longitude DECIMAL(9,6)
);

-- weathers table
CREATE TABLE weathers (
    id INT AUTO_INCREMENT PRIMARY KEY,
    city_id INT NOT NULL,
    temperature DECIMAL(5,2) NOT NULL,
    humidity INT NOT NULL, -- stored as percentage
    pressure INT NOT NULL, -- stored as hPa
    recorded_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (city_id) REFERENCES cities(id)
);

A single weathers_cities table would only make sense if you never need to track historical weather data (only keep the latest reading per city) and don't care about database normalization—but since you're updating hourly, you'll almost certainly want to track those changes over time.

内容的提问来源于stack exchange，提问作者J.J. Beam