Тут согласен, я пока не видел ни разу даже применения этих методов
Но вот с четверкой тут прям интуитивно уже должно быть понятно, что-бы люди строили апишки по какой-то договорённости

Например, задача с восстановлением удаленных данных. Встречал отдельный endpoint с PUT, встречал тот же endpoint, но с методом PATCH. И бог его знает, как правильно

Тоесть в ресте лучше иметь меньше роутов и больше "флагов" который будут влиять на ответ ?

Пример щас дам

Вот мне кажется как раз PATCH т.к. это менее частный случай. + восстановление удалённых данных часто может подразумевать изменение колонки isDeleted на false в таблице, а это уже даже не POST а PUT выходит
Но кейс то однобокий, поэтому реально PATCH лучше подходит

Есть пользователь который может создаваться по 2 разных способах. Завися от  2 переменных.
лучше делать /api/users POST и там просто делать 2 переменные optional и завися от того которая пришла выдавать ответ.
или создать липо /api/users/custum который будет принмать 1 поле и
/api/user/template
который будет принимать другое поле ?

Суть в том что пользователь может быть создан от теплейта  или вручную на писан

Ну флагов немного грубо сказано. Лучше сказать критериев для типа ответа

Например 'https://mybackend/api/products?top=10&offset=5&status=1&maxprice=1000

Выдаст список из 5 продуктов с 10го, статусом 1 (допустим статус 1 это те которые со скидками) и макс ценой 1000

А представь как это разбить на эндпоинты?
Один для акционных, другой для вырезки из всего списка, другой для тех которые с ограниченной ценой. И ладно это нужно по отдельности, а теперь хоба - надо все и сразу

А тут банально на фронте настроил запрос и получил все как хотел, как два байта в ОЗУ

Ты вроде говорил можно отправить либо имя, либо фамилию, и при этом пользователь должен быть создан, правильно?

Ну я типо придумаю на самом деле у меня другой кейс, больше похож на пример выше с темплейтами

Ну вот пример с POST запросом

POST - '.../api/car'
а в body такой интерфейс {
  color: string,
  wheels: number
  width: number,
}

Теперь ты можешь описать настройки по умолчанию
{
color: 'white',
wheels: 4,
width: 2.3
}

И когда тебе приходит запрос, ты делаешь слияние того что есть, с тем что пришло

const params = Object.assing({}, defaultParmas, youParams); (тут мог порядок попутать, надо доку посмотреть)

И если ты отправил только цвет, то у тебя уже по умолчанию будет 4 колеса и ширина 2.3 метра

И не надо плодить эндпоинты на колёса, на цвет, на ширину

Понял

Прив.
Не подскажите как эмулировать ошибку в роуте, чтобы она попала в middleware приложения?

app.use(function (err, req, res, next) {
 console.error(err)
})

throw new "STOP"

res.status(404).send(null) или так

подскажите, почему при коннекте к серву вылетает ошибка Failed to connect to SERVER\SQL2016:1433 - getaddrinfo ENOTFOUND SERVER\SQL2016


подключение

import { Sequelize } from 'sequelize-typescript'
import { environment } from '../config'
import { normalize, join } from 'path'
export default new Sequelize({
  database: environment.database.database,
  dialect: "mssql",
  username: environment.database.username,
  // port: environment.database.port,
  password: environment.database.password,
  host: environment.database.host,
  logging: !environment.production ? console.log : false,
  models: [normalize(join(__dirname, "..", "models"))],
  dialectOptions: {
    options: {
      enableArithAbort: true,
      cryptoCredentialsDetails: {
        minVersion: "TLSv1",
      },
    },
  },
})

пробую и с портом и без него, ошибка та же.
Если через Management Studio пробую то коннектит

Спс

router.get('/', (req, res, next) => {
 res.status(404).send('error')
})

app.use(function (err, req, res, next) {
 console.log('error:', err)
})

Не работает(

Ну так это ошибка запроса, а не в коде выходит. Выбрось исключение

Как?