|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat Для меня, как для разработчика, код контроллера это такая же спека, как все то же самое описанное на yaml/json. История показывает, что все эти подходы "понарисуем квадратиков со стрелочками, а чудо-инструмент нам сам по ним код сгенерирует" это полный фейл. Лет десять назад резюме разработчика без упоминания UML это было вообще не резюме. Ну и где сейчас этот UML - впиши его в резюме и тебя засмеют :)) Единственное применение кодогенерации сервера что я сразу так вижу, это когда тебе надо реализовать какой-то чужой API точно в соответствие с чужой спецификацией (например web-hooks для стороннего сервиса) Не, ты путаешь слегка. OpenAPI это весьма конкретная спецификация, которую можно быстро разрабатывать. Квадратики это вообще маст хев, но в квадратики 90% людей не умеют, поэтому как пещерные аборигены, объясняют на пальцах, пишут код на основе туманных тезисов, которые каждый понимает по-своему. Отсутствие качественного анализа и постановки с "квадратиками" выливается в большое количество мусорной бесполезной коммуникации, дефектов и отладки. Тебе нужно не только контроллер, но и модели + аннотации + комментарии + инварианты ответов с описаниями. А потом если что не так? В спецификации OpenAPI нужно поправить несколько строк, а контроллерах всё переколбашивать. Просто ты с таким не сталкивался, сам так работал и понимаю тебя прекрасно. Однако на основе более глубокого опыта, разработка спецификации до написания кода -- эффективнее на порядочек. При любых раскладах практически. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:27 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat Я выше писал - интерфейс контроллеров и акций это ровно такая же спецификация API как и OpenAPI Doc, просто в другом формате, причем генерировать одно из другого можно и в ту и в другую сторону. Тут, наверное, просто вопрос, с чем команде удобней работать - описывать API на C# или на YAML/JSON. Точно так же как в древние времена COM - ты мог сначала написать кодом интерфейсы, а потом из них сгенерировать IDL/TypeLib, а мог наоборот - написать сначала IDL, а из него сгенерировать интерфейсы - и то и другое абсолютно равнозначно. А теперь представь, тебе надо заинтегрироваться с другой командой. Тебе нужно, чтобы они тебе АПИ выставили, не один метод с парочкой полей, а несколько, допустим десяток со структурами разной сложности. Именно для тебя. Ты к ним обращаешься, они согласны. Говорят, присылай спеку, мы реализуем. Контроллер будешь колотить на коленке? Ну вот это колхоз. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:29 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt Говорят, присылай спеку, мы реализуем. Ну если так, тогда да. Я ведь раньше еще тут писал, что сценарий со спекой как раз хорошо подходит для реализации чужого API. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 19:29 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat hVostt Говорят, присылай спеку, мы реализуем. Ну если так, тогда да. Я ведь раньше еще тут писал, что сценарий со спекой как раз хорошо подходит для реализации чужого API. Не обязательно. Давай тебе кейс. Есть команда бек, есть команда фронт. Проект один. Ты пилишь свои задачи, фронт свои. Завтра спринт заканчивается, и надо начать пилить новые задачи. По твоей методике, получается, фронт должен сидеть ждать пока ты свои контроллеры напишешь? :) А если вдруг что-то на фронте не зайдёт, они не заценят твою сгенерированную спеку, будут замечания, код переписывать? Как бы вовсе не чужое API, а твоё. Но спека нужна раньше, чем начнётся реализация. Да она может и поменяться в процессе, подкорректироваться, но необходимо максимально снизить подобные ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 19:40 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt По твоей методике, получается, фронт должен сидеть ждать пока ты свои контроллеры напишешь? :) А зачем писать контроллеры? Я же опять-таки выше уже писал - достаточно написать только интерфейсы контроллеров. Написал интерфейсы - кинул им ссылку на /swagger и пускай себе пилят, а ты пили уже реализацию своих контроллеров. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 19:55 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt Квадратики это вообще маст хев, но в квадратики 90% людей не умеют, поэтому как пещерные аборигены ЛОЛ, так это именно пещерные аборигены общались тем, что жирафов да бегемотов на стене рисовали, а развитые люди чтобы общаться как раз и придумали алфавит и письменность ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 19:58 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat hVostt По твоей методике, получается, фронт должен сидеть ждать пока ты свои контроллеры напишешь? :) А зачем писать контроллеры? Я же опять-таки выше уже писал - достаточно написать только интерфейсы контроллеров. Написал интерфейсы - кинул им ссылку на /swagger и пускай себе пилят, а ты пили уже реализацию своих контроллеров. Так по сути контроллеры и есть интерфейсы, не? :) 90% кода контроллеров -- интерфейс. Это модели данных, аннотации, комментарии, инварианты ответов, маршруты, политики, полный фарш. fkthat ЛОЛ, так это именно пещерные аборигены общались тем, что жирафов да бегемотов на стене рисовали, а развитые люди чтобы общаться как раз и придумали алфавит и письменность Так развитые не по одним лекалам. Поэтому нужны наглядные изображения бизнес-процессов, те самые "квадратики", согласованный словарь и куча всего, чтобы коммуникация была эффективной. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 20:05 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt Это модели данных, аннотации, комментарии, инварианты ответов, маршруты, политики, полный фарш. Ну так все это по любому придется и в JSON писать. Тот же фарш только в другом виде. hVostt Так по сути контроллеры и есть интерфейсы, не? Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 20:16 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat, ну так тебе надо написать код, скомпилить, запустить, открыть страничку со сваггером, вытащить файл, отдать. и хрен бы сним, щитаешь это удобным -- ок. каждый извращается как может, ноу проблем )) а теперь в твоём сваггере вносят комментарии/изменения, как обратно "фарш" затолкаешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 20:37 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt ну так тебе надо написать код, скомпилить, запустить, открыть страничку со сваггером, вытащить файл, отдать. А если все это делать в обратном порядке (от JSON к коду контроллера), то количество шагов сильно меняется? И, вот как это выглядит в C#: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
А вот, как то же самое выглядит в OpenAPI (слабонервным спойлер лучше не открывать ) Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 00:19 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt, А еще, кстати, когда ты будешь писать свой мультикилометровый JSON, то тебе придется регулярно генерить из него код, чтобы проверить что он вообще генерится и что генерится то, что ты ожидаешь. А когда я буду писать свой C#, то у меня студия сама сразу будет мои косяки подсвечивать :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 01:03 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat А если все это делать в обратном порядке (от JSON к коду контроллера), то количество шагов сильно меняется? На этапе разработки и согласования API меняется конечно. Более того, если для тебя это станет привычным, ты только выигрываешь во всех отношениях. fkthat А вот, как то же самое выглядит в OpenAPI (слабонервным спойлер лучше не открывать ) Прекрасно выглядит. Но только не в JSON: Код: python 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
fkthat А еще, кстати, когда ты будешь писать свой мультикилометровый JSON, то тебе придется регулярно генерить из него код, чтобы проверить что он вообще генерится и что генерится то, что ты ожидаешь. А когда я буду писать свой C#, то у меня студия сама сразу будет мои косяки подсвечивать :)) Зафига мне мультикиллометровая спека, я её могу побить на кучу маленьких, на каждую задачу свой кусочек. Её можно затолкать в гит и видеть именно изменения в спецификации. Т.е. я внесу изменения, и все увидят понятные изменения, все потребители АПИ. Более того, в её разработке могут участвовать все: бек, фронт, аналитики, потребители. А когда ты внесёшь изменения в контроллеры и модели, кто поймёт какие конкретно изменения отразятся на АПИ? Никто. Кроме тебя. Просто ты АПИ полностью лочишь на себе. Индивидуально с твоей точки зрения -- это конечно хорошо. Теперь все пляшут и танцуют вокруг тебя :) Но с командной точки зрения и в целом для разработки проектов -- это крайне хреновый подход. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 23:24 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat, Я в общем, рекомендую попробовать. Возьми, например, вот это: https://marketplace.visualstudio.com/items?itemName=42Crunch.vscode-openapi Ты получишь вменяемый редактор спеки с интеллисенсом, валидацией и всей остальной фигнёй. Ни чем абсолютно не отличается от написания кода на C# :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 23:27 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt fkthat, Я в общем, рекомендую попробовать. Возьми, например, вот это: https://marketplace.visualstudio.com/items?itemName=42Crunch.vscode-openapi Ты получишь вменяемый редактор спеки с интеллисенсом, валидацией и всей остальной фигнёй. Ни чем абсолютно не отличается от написания кода на C# :) Посмотрю. Да только у меня тут новый проект, где у людей вообще только POST, и, (внимание!), всегда возвращается только 200, а если какая-то ошибка, то она передается в body неким магическим кодом. Когда я спросил, что это за ХЕРНЯ, то меня "успокоили", тем, что все эти коды ошибок у них в конфлюенсе задокументированы. Вот так вот. А ты мне тут про OpenAPI. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 00:06 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat Посмотрю. Да только у меня тут новый проект, где у людей вообще только POST, и, (внимание!), всегда возвращается только 200, а если какая-то ошибка, то она передается в body неким магическим кодом. Когда я спросил, что это за ХЕРНЯ, то меня "успокоили", тем, что все эти коды ошибок у них в конфлюенсе задокументированы. Вот так вот. А ты мне тут про OpenAPI. Эээ, я с таким уже сталкивался :) Забирали проект от внешнего подрядчика, а там типа того, POST, иногда GET и все ответы только 200. На мой вопрос, это чё за херня, мне ответили, это JRPC... Прастите што? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 00:09 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt, помнишь, на сайте как то была бурная дискуссия про то как ответы в web api оформлять - вариант 1 - коды ответов 200, 400 500 использовать и давать тело ответа вариант2 - код ответа 200 для успешного ответа и 500 для ошибок в ваших проектах вы что используете ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 09:54 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
monstrU hVostt, помнишь, на сайте как то была бурная дискуссия про то как ответы в web api оформлять - вариант 1 - коды ответов 200, 400 500 использовать и давать тело ответа вариант2 - код ответа 200 для успешного ответа и 500 для ошибок в ваших проектах вы что используете ? Меня, вот еще интересует. Надо ли по best practice перечислять "очевидные" статусы - 401, 403, 500, или это лишнее. 200 надо указывать явно, потому что успешный ответ это не всегда 200, а может быть и любой другой двухсотый, те же, например, 201, 202, 204. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 10:15 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
monstrU hVostt, помнишь, на сайте как то была бурная дискуссия про то как ответы в web api оформлять - вариант 1 - коды ответов 200, 400 500 использовать и давать тело ответа вариант2 - код ответа 200 для успешного ответа и 500 для ошибок в ваших проектах вы что используете ? Не все ошибки это 500. 500 это значит "неизвестный песец на сервере". Поэтому возвращать всегда 500 это полнейший говнодизайн. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 12:22 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat Меня, вот еще интересует. Надо ли по best practice перечислять "очевидные" статусы - 401, 403, 500, или это лишнее. Совершенно лишнее. Вот здесь много чего интересного: https://swagger.io/docs/specification/describing-responses/ Смотри разделы "Default Response" и "Reusing Responses". fkthat Не все ошибки это 500. 500 это значит "неизвестный песец на сервере". Поэтому возвращать всегда 500 это полнейший говнодизайн. Можно считать, что 500 означает, что требуется чинить. "Рядовых" 500 быть не должно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 18:52 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
monstrU помнишь, на сайте как то была бурная дискуссия про то как ответы в web api оформлять - вариант 1 - коды ответов 200, 400 500 использовать и давать тело ответа вариант2 - код ответа 200 для успешного ответа и 500 для ошибок в ваших проектах вы что используете ? вариант 1, кодов ответов больше. надо понимать, что код ответа нужен не для удовлетворения внутреннего перфекциониста. а для вполне конкретных задач. для организации единого мониторинга и построения понятного API. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 18:54 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
hVostt, я по архитектуре веб сервисов дальше рассуждаю - рассматриваю какой вариант. возьмем абстрактный пример получение по номеру паспорта ФИО и даты рождения человека. то есть имеем сервис /passport/person?passportNumber=41001234 и по нему возвращаем ответ 200 и тело запроса Код: javascript 1. 2. 3. 4. 5. 6. 7.
на запрос /passport/person?passportNumber=4100123 возвращаем ответ 400 и тело Код: javascript 1. 2. 3. 4.
то есть подход какой - веб сервис возвращает не объект, а ответ на запрос. а он уже состоит из ответа, когда он есть, или из объяснения причины отказа в ответе - отказ запроса по бизнес требованиям. как то у меня такой подход сложился - у вас как ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2020, 15:46 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
monstrU то есть подход какой - веб сервис возвращает не объект, а ответ на запрос. а он уже состоит из ответа, когда он есть, или из объяснения причины отказа в ответе - отказ запроса по бизнес требованиям. как то у меня такой подход сложился - у вас как ? Да, вполне очеь даже нормальный подход. Только я бы возвращал завернутое в массив, потому что по REST URI типа /passport/person это коллекция и возвращать следует коллекцию. Если бы URI были типа /passport/person/41001234 то тогда либо 200 + объект, либо 404. Я придерживаюсь такого, что все что до "?" это URI ресурса, а все что после "?" это некие параметры представления этого ресурса (например, фильтрация, сортировка, пейджинг и т.п.). Что-то плохое до вопроса - это 404 (ресурса нет), а все что плохое после вопроса - это 400 - ресурс есть, но запрос к нему кривой. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2020, 16:22 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
monstrU то есть подход какой - веб сервис возвращает не объект, а ответ на запрос. а он уже состоит из ответа, когда он есть, или из объяснения причины отказа в ответе - отказ запроса по бизнес требованиям. как то у меня такой подход сложился - у вас как ? Если сложился, то хорошо. Но лично на мой взгляд плохо. Благодаря коду ответа (например, 200/400) мы имеем возможность легально возвращать разные типы данных. Соответственно, педалить один и тот же тип со значимыми полями, которые могут содержать null в случае ошибки -- хреново. Т.е. содержать структуру, которая содержит Payload, (в вашем случае 'Response'), это прям убер костыль. Масло маслянное, HTTP уже даёт мощные инструменты для реализации чистого АПИ. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2020, 01:53 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
fkthat, обращу внимание - возвращается ответ веб сервиса, поэтому объект с ответом один. в моем примере веб сервис возвращал только одну персону, поэтому объект с ответом был 'Response':{ 'FIO':'Путин Вова', 'BirthDaty':'19600201' }, если бы веб сервис был такой, что возвращает несколько персон, то само собой нужно было написать 'Response':[{ 'FIO':'Путин Вова', 'BirthDaty':'19600201' }] hVostt, объясню откуда выполз 'Response':null, для подключения к веб-сервисам сделали агента на серверной стороне, который как раз возвращает CS объект с ответом веб сервиса. Физическое подключение было сделано библиотекой, которая сама ответ сериализовывала в cs объект (RestSharp был использован) В случае невалидных параметров при коде 400 архитектура потребовала 1. выдать массив с разъяснением причин отказа проверки 2. и для успешной сериализации ответа поставить 'Response':null, так как Response заполняется в случае успешного ответа 200 Так что получилось, что когда пользуешься библиотекой с автоматической сериализацией ответа то оказалось удобно для 400 использовать вот такую структуру { 'Response':null, Explanations:['в номере паспорта должно быть 8 символов'] } Да и архитектурно получается вроде логичное объяснение: при отказе при валидации нет ответа веб сервиса и есть разъяснение причин отказа fkthat, hVostt вообще мнение по вопросу опять поделилось - один голос сказал за, второй голос против. кстати в прошлом топике про веб апи так же было. так что видимо на уровне предпочтений. мой пример вылез из того, что реально загрузкой занимается библиотека с автоматический сериализацией ответа ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2020, 07:08 |
|
Web API. Как открыть интерфейсы?
|
|||
---|---|---|---|
#18+
monstrU fkthat, обращу внимание - возвращается ответ веб сервиса, поэтому объект с ответом один. в моем примере веб сервис возвращал только одну персону, поэтому объект с ответом был 'Response':{ 'FIO':'Путин Вова', 'BirthDaty':'19600201' }, если бы веб сервис был такой, что возвращает несколько персон, то само собой нужно было написать 'Response':[{ 'FIO':'Путин Вова', 'BirthDaty':'19600201' }] Да можно и так, в общем-то, в REST что и плохо, что нет по сути никаких стандартов. Просто, допустим, мы решили доработать наш API поддержкой запроса /passport/person/?firstName=Вова и тогда он уже будет возвращать: Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Получится не очень удобно. Все-таки, на мой вкус, запрос к коллекции должен возвращать коллекцию. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2020, 07:43 |
|
|
Start [/forum/topic.php?fid=19&msg=40015370&tid=1396648]: |
0ms |
get settings: |
26ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
491ms |
get tp. blocked users: |
2ms |
others: | 345ms |
total: | 957ms |
0 / 0 |