Отличный материал. Для новичка супер! Я бы ещё посоветовал сделать видео про модель данных. Связи. На примерах из реальных проектов. Потому что все в основном объясняют на библиотеках) книга автор и т.д.
errorCode мой случай) бизнес логика может содержать свои состояния. Например http может быть 200 но по бизнес логике запрос будет отклонен - не страшно. Но например по бизнес логике нужно передать успешный код в параметре errorCode. С точки зрения семантики может здесь лучше использовать например statusCode? Как правильно, поделитесь?
Воо, отличный пример)) В вашем случае, соглашусь, errorCode точно как-то не очень будет выглядеть. statusCode гораздо лучше, главное, что бы все участники процесса четко отличали его от http status code (в документации, в openApi спецификации).
Получилось так что этот видеоролик посмотрел только сейчас. Ваш пример мне очень помог в понимании написания методов с телом запроса. Сам Swagger воспринял теперь мой "код описания" без каких-либо ошибок. Но при попытке ввода новых значений после нажатия кнопки "Tty it out", в области "Code", возвращает не успешный код 200, а следующую ошибку: TypeError: Failed to execute 'fetch' on 'Window': Failed to read the 'headers' property from 'RequestInit': String contains non ISO-8859-1 code point. Как думаете, как можно привести описание в соответствие с этим стандартом ISO? Как понять что именно в описании не соответствует этом стандарту?
Интересный вопрос на самом деле. Смахивает на то, что где-то затесались спец символы, такие как " ", "\t" и тд. А можете уточнить, вы сначала создаете openapi спецификацию, затем в swagger ui нажимаете try it out? Или вы из кода автоматом по аннотациям получаете спецификацию?
Интересно что "Метод предназначен для получения уведомления со статусом выполнения переданного ранее запроса." реализован через post, логичнее вроде как по restful через get. Можете уточнить почему так?
Хорошее замечание. Действительно, немного неочевидно со стороны, это детали реализации моего сервиса. Процесс получение уведомления - это процесс, когда мой сервис получает уведомление от инициатора http запроса:) Соответственно приравнивается к созданию новой сущности, поэтому и был post. Но я соглашусь с вами, что с точки зрения api корректнее назвать метод создания уведомления.
Технически ничего же не мешает удалять по гет. Когда придет понимание этого, останутся "договоренности", а точнее правила, описанные в трудах мистера Roy Fielding
@IT_like_bricks_building технически то да, но дело не в каких то там правилах. Правила вторичны, пишутся, исправляются и дополняются на основе чего-либо, это не первоисточник. Например, нельзя переходить дорогу на красный свет. Это значит нельзя переходить дорогу потому что есть такое правило, а потому что это опасно ) В данном случае, get нельзя использовать для внесения изменений на сервере просто потому что отрасль развивалась так, что всем плевать что там будет делать сервер, ведь декларировано что это запрос получения данных. Поэтому браузер или любая другая среда, например мессенджер или текстовый редактор, может сделать префеч в любой момент.
Это отличный холиварный вопрос для собеседований. Главное не ответ можно или нельзя, а то почему человек так считает. Я с вами согласен, так как оба ответа правильны, если привести причины
