Ответ
Технически — да, но с точки зрения RESTful-архитектуры и семантики HTTP — это противоречивая практика.
Стандартный подход (REST):
- Метод
POSTна коллекцию (например,/api/users) предназначен для создания нового ресурса, идентификатор которого должен быть сгенерирован на стороне сервера (часто в БД). Клиент не должен знать или указывать этот id заранее. - Успешный ответ
201 Createdобычно содержит заголовокLocationс URL нового ресурса (например,/api/users/123) и может включать созданный объект в теле.
Пример на Express.js:
app.post('/api/users', async (req, res) => {
const userData = req.body; // { name: 'Alice', email: 'alice@example.com' }
// id НЕ ожидается в userData
const newUser = await db.users.create(userData); // Сервер генерирует id
res.status(201).location(`/api/users/${newUser.id}`).json(newUser);
});
Когда передача id в POST может иметь смысл (но лучше избегать):
- Импорт данных: При массовом импорте существующих данных из другой системы, где id нужно сохранить.
- Специфичная бизнес-логика: Если идентификатор является не техническим ключом БД, а частью бизнес-данных (например, артикул товара, который задает клиент).
Альтернативы:
- Для операций, где клиент определяет ключ ресурса, более семантически верным является метод
PUTна конкретный URL (например,PUT /api/users/alices-article-number).PUTидемпотентен и означает «создать или полностью заменить ресурс по данному идентификатору».
В моих проектах на Node.js я строго следую принципам REST: POST для создания без указания id, PUT/PATCH для обновления по известному id. Это делает API предсказуемым и понятным для всех разработчиков.