Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Описание REST API  [new]
maslinka
Member

Откуда: от верблюда
Сообщений: 286
есть документ, описание REST API . необходимо в enterprise archichitect нарисовать схему. Как вообще это все примерно можно изобразить в в enterprise archichitect в какой диаграмме?

Пожалуйста, помогите.
17 сен 18, 10:12    [21676410]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26479
maslinka,

схему чего Вы хотите изобразить?
17 сен 18, 12:08    [21676630]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26479
Что человек из этой схемы должен понять?
17 сен 18, 12:10    [21676636]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
alex55555
Member [заблокирован]

Откуда:
Сообщений: 2129
skyANA
Что человек из этой схемы должен понять?

Не человек, а начальник.

Пора бы уже понять, чего хотят неопытные девочки :)

Ей кто-то дал "документ" и сказал его отразить на некой схеме, которую они то-ли пытаются родить, то ли уже родили, но тот, кто документ дал, понятия не имеет, где (и главное - зачем) на этой схеме должен поминаться предложенный документ. Девочка тоже понятия не имеет. Ну и спрашивает.

А вам, девушка, очередной совет - давайте больше информации. Не дадите - не получите ответа.
17 сен 18, 12:52    [21676730]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26479
alex55555
Пора бы уже понять, чего хотят неопытные девочки :)

alex55555
А вам, девушка, очередной совет - давайте больше информации. Не дадите - не получите ответа.

И зачем тебе больше информации, чтобы дать вразумительный ответ, если ты чётко понимаешь, чего хотят неопытные девочки?
17 сен 18, 13:15    [21676779]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7680
Когда-то видел он-лайн репозиторий для описания REST-API. Вполне себе было прилично сделано. Относительно структурированное описание + совместная работа.

Когда договаривался о халтуре, там народ свои REST-API хранили/описывали. Адреса не помню (((
17 сен 18, 14:38    [21676941]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7680
Нашел обзор разных документаторов для API, но я видел что-то другое ((( какой-то стартап (((

https://pronovix.com/blog/free-and-open-source-api-documentation-tools
17 сен 18, 14:42    [21676950]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
maslinka
Member

Откуда: от верблюда
Сообщений: 286
да все верно про
alex55555
Ей кто-то дал "документ" и сказал его отразить на некой схеме, которую они то-ли пытаются родить, то ли уже родили, но тот, кто документ дал, понятия не имеет, где (и главное - зачем) на этой схеме должен поминаться предложенный документ. Девочка тоже понятия не имеет. Ну и спрашивает.


все верно. хоть и смешно.

надо в enterprise architect описать rest api и как из интерфейса (формы) параметры передаются rest api.
18 сен 18, 10:50    [21677765]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
maslinka
Member

Откуда: от верблюда
Сообщений: 286
Leonid Kudryavtsev
Нашел обзор разных документаторов для API, но я видел что-то другое ((( какой-то стартап (((

https://pronovix.com/blog/free-and-open-source-api-documentation-tools


про сваггер я знаю. не то. надо картинки, схемы.
18 сен 18, 10:51    [21677767]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 647
maslinka
надо в enterprise architect описать rest api и как из интерфейса (формы) параметры передаются rest api.


Не понятно зачем вообще это диаграммой рисовать, можно просто табличку сделать: параметр такой из комбобокса1, параметр такой то из текстбокса такого то с соответствующими преобразованиями.
Но раз уж хочется диаграмму ну нарисуйте диаграмму классов сервиса и GUI интерфейс и стелочками из контролов формы соедините с атрибутами соответствующего класса.
Но по мне это извращение. Просите того кто поручил конкретизировать задачу, подозрение что он сам не шарит в UML.
Кстати он холост? Может в этом все дело?
18 сен 18, 11:27    [21677830]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
maslinka
Member

Откуда: от верблюда
Сообщений: 286
skyANA
Что человек из этой схемы должен понять?


человек должен понять как передаются параметры из формы в рест апи.

ну так как я не разработчик мне многие задачи для понимания даются очень сложно
18 сен 18, 11:31    [21677836]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
maslinka
Member

Откуда: от верблюда
Сообщений: 286
Serguei
maslinka
надо в enterprise architect описать rest api и как из интерфейса (формы) параметры передаются rest api.


Не понятно зачем вообще это диаграммой рисовать, можно просто табличку сделать: параметр такой из комбобокса1, параметр такой то из текстбокса такого то с соответствующими преобразованиями.
Но раз уж хочется диаграмму ну нарисуйте диаграмму классов сервиса и GUI интерфейс и стелочками из контролов формы соедините с атрибутами соответствующего класса.
Но по мне это извращение. Просите того кто поручил конкретизировать задачу, подозрение что он сам не шарит в UML.
Кстати он холост? Может в этом все дело?


да вот так я и отрисовываю. спасибо
18 сен 18, 11:31    [21677839]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
alex55555
Member [заблокирован]

Откуда:
Сообщений: 2129
maslinka
да вот так я и отрисовываю. спасибо

Ну вот и славно. Помощь оказана :)
18 сен 18, 13:52    [21678105]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
maslinka
Member

Откуда: от верблюда
Сообщений: 286
alex55555,

спасибо. как вот я должна была сама до этого догадаться?
18 сен 18, 14:03    [21678125]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
alex55555
Member [заблокирован]

Откуда:
Сообщений: 2129
maslinka
как вот я должна была сама до этого догадаться?

А я думал вы настоящий аналитик. Они ведь такие - сами иногда догадываются о чём их просят.

А если не догадываются, то спрашивают окружающих - ну как вот так я тут что-то могу придумать? А ну быстро расскажите мне! :)

На самом деле ряд ваших уточнений избавил советчика от сомнений. А если бы были сомнения, он мог бы и не написать. Отсюда вывод - вы даёте мало информации и её из вас клещами приходится вытягивать.
19 сен 18, 13:59    [21679525]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Bsplesk
Member

Откуда:
Сообщений: 113
maslinka,

Смотри, большинство документаций api это не просто текст - это контракт/договор(описание интерфейса взаимодействия с сервисами, которые предоставляет API), по которому можно сгенерировать исходный код без логики реализации и обратно (вот этот код можно описать в UML - но зачем? по факту описания swagger достаточно - если, конечно, нет цели вести описание "объектов" централизованно и переиспользовать объекты,структуры данных) .
Чисто - документация это позапрошлый век.

Есть два основных подхода:
- contract first
- code first
Для начала тебе нужно определить каким образом было/будет разработано? данное API.
Если API уже есть и контракт, то можно забить, пофик, как реализовано.

Что нужно то?

- Описать API? Swagger и есть описание/контракт(интерфейс). Отвечает на вопрос: Как работать с сервисами предоставляемыми данным API? - больше ничего не требуется, всё должно быть описано в контракте.
- Создать описание работы реализованных сервисов(еще называют паспортами сервисов) API ?, Отвечает на вопрос: как работает сервис (внутри) - обычно рождается после разработки по ТЗ или без ТЗ(Отвечают на вопросы, как должен быть разработан/доработан данный сервис), служит вводной для нового разработчика/тестировщика/архитектора/аналитика. Обновляется в течении жизни сервиса, обычно текст + дополненный UML/ER диаграммой по необходимости. Самое сложное, рутинное, блевотное.
- Описать интеграционные потоки взаимодействия с сервисами данного API (обычно часть паспорта), текст + UML Sequence/BPMN. Отвечает на вопрос: Кто и как взаимодействует/использует с данным сервисом.

P.S.
Одна модель данных описанная на (на форме) к примеру маппится на соответствующую модель описанную в swagger.
С этим в UML - ЖОПА, ПОЛНАЯ.

О чем и сказано на сайте вашей программулины:

Data Mapping in UML
Written by DT_Sam

It’s often the case that we need to map various attributes on entities into other entities. For example you might need to migrate data from one system to another and structurally the same concepts are held slightly differently. Documenting these mappings is not obvious in the UML, so below I’ve provided a simple example of how a composite structure diagram could be used to provide the mappings. Some notes have been added where conversions need to be performed and these could be represented more formally using diagram references to behavioural diagrams such as sequence or activity diagrams. This is quite possibly not 100% UML compliant / intended usage; but it provides a tool for this type of mapping which otherwise seems to be lacking in the standard UML specification.


https://community.sparxsystems.com/white-papers/623-95data-mapping-in-uml
http://www.sparxsystems.com/forums/smf/index.php?topic=25999.0

Используете: Excel/altova mapforce... etc
К текстовому описанию логики маппинга(сопоставления) - можно приложить uml activity, но обычно там все просто и достаточно текста.
23 сен 18, 20:59    [21683353]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
maslinka
ну так как я не разработчик мне многие задачи для понимания даются очень сложно

значит не лезьте глубоко в механику этого API или REST API.
Умейте провести красную линию для себя куда вы не лезете (реализацию).
У вас должно быть всё понятно не программисту в стрелочках и квадратиках.
И поэтому для аналитика мешает знание программирования.
Он начинает лезть не в свою область и думать слишком мелко.
Например думать о каких то "формах".
Нет в REST API никаких форм.

maslinka
и как из интерфейса (формы) параметры передаются rest api.

это слишком мелкая задача.
Лушне не "как", а "что".
Т.к. слово "как" это уже реализация.
Построение урл для ресурса с REST API:
https://restfulapi.net/resource-naming/
25 сен 18, 07:27    [21684897]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Bsplesk
Member

Откуда:
Сообщений: 113
Petro123
maslinka
ну так как я не разработчик мне многие задачи для понимания даются очень сложно

Построение урл для ресурса с REST API:
https://restfulapi.net/resource-naming/


offtop

REST - это круто :).
Простейший пример: есть клиент, есть карта, у карты есть pin и cvc, вещи эти отдельные, в одном объекте несовместимые, эти данные хранить нельзя они вычисляются при каждом запросе и передаются по разным каналам в одну операцию(вычисли и отправь - разделить на два метода нельзя, ибо хранить эти данные запрещено), при этом cvc динамический - id у него нет:

Как предлагается реализовывать соответствующий REST?

GET: /clients/{clientId}/cards/{maskedPan}/cvc ?
POST: /clients/{clientId}/cards/{maskedPan}/cvc ?

Всё, приехали - CRUD для описанной выше задачи не катит, он вообще мало для чего катит на самом деле

Что "новопридуманный" контроллер делать? - а по факту функцию, привет удаленный вызов процедур(RPC), и причем тут REST :) ?

controller

A controller resource models a procedural concept. Controller resources are like executable functions, with parameters and return values; inputs and outputs.

Use “verb” to denote controller archetype.

http://api.example.com/cart-management/users/{id}/cart/checkout
http://api.example.com/song-management/users/{id}/playlist/play
-------------------------------------------------

POST: /clients/{clientId}/cards/{maskedPan}/cvc/send ?
или
POST: /clients/{clientId}/cards/{maskedPan}/cvcSending/send ?
25 сен 18, 13:24    [21685375]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
Bsplesk
REST - это круто :).
Простейший пример: есть клиент, есть карта, у карты есть pin и cvc

А причём тут REST?
Просто неверный выбор технологии для задачи.
25 сен 18, 13:39    [21685405]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26479
Bsplesk
offtop

REST - это круто :).
Простейший пример: есть клиент, есть карта, у карты есть pin и cvc, вещи эти отдельные, в одном объекте несовместимые, эти данные хранить нельзя они вычисляются при каждом запросе и передаются по разным каналам в одну операцию(вычисли и отправь - разделить на два метода нельзя, ибо хранить эти данные запрещено), при этом cvc динамический - id у него нет:

Как предлагается реализовывать соответствующий REST?

Как API к операциям. Обсуждали это уже.
25 сен 18, 13:42    [21685410]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26479
Bsplesk, вот:

Rest. А как реализуются методы с логикой сложнее чем Добавить/Удалить ?
25 сен 18, 13:44    [21685413]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Bsplesk
Member

Откуда:
Сообщений: 113
Petro123
Bsplesk
REST - это круто :).
Простейший пример: есть клиент, есть карта, у карты есть pin и cvc

А причём тут REST?
Просто неверный выбор технологии для задачи.


Она же у нас 2-3:1 аналитик/архитектор.
Вероятно ей рано или поздно придется участвовать в проектировании API.
В том числе заниматься выделением бизнес объектов ой ресурсов и их связей (да, да те самые 1-1, 1-N ... etc), который станут "строительными блоками api", а REST сейчас пихают куда только можно и нельзя (хотя хайп пошел на спад). Тут приведена простая, тривиальная бизнес задачка не влезающая в рамки пропагандируемых реализаций архитектурного стиля REST.
Ей, как аналитику/архитектору нужно уметь "Впихнуть невпихуемое", а лучше уметь отстаивать свою точку зрения.
Картинка с другого сайта.

skyANA
Bsplesk, вот:

Rest. А как реализуются методы с логикой сложнее чем Добавить/Удалить ?


Что вот? три страницы срача? - точнее "как натянуть сову на глобус", достаточно посмотреть реализации многих API TOP компаний, чтобы понять, что каждый сам как может у каждой компании свое видение.

https://restfulapi.net/resource-naming/ --> тут же в комментариях "срач" аналогичный.

Sean says
November 8, 2017 at 6:25 am
checkout is a verb and play are verbs and as you point out at the start it is considered bad practice to use verbs in the URI.
“RESTful URI should refer to a resource that is a thing (noun) instead of referring to an action (verb)”
Also you haven’t mentioned which HTTP method should be called for the controller pattern but if it is GET then you are changing state via a method that should be idempotent.
If it is POST then the controller pattern is RPC rather than REST. A RESTful API would allow the retrieval of the “checkout” resource via
“GET http://api.example.com/cart-management/users/{id}/cart/checkout”
which doesn’t seem to make sense as a request.
It would be better IMO to include a status attribute in the cart resource and update that.

Что предлагает господин admin? - правильно очередное костылище, используйте, что угодно, но только не вздумайте обозвать с чем-то логически намекающем на: CRUD.
Итого имеем не CRUD, а CRAHCFFDERTFCVFDSTRDCVGFCERSDFYUIKLPOKJYUFRSDFVBYFYGTRDREDCVGFJHCRYSDXCFCFCV, простое логичное api.

Admin says

November 10, 2017 at 11:50 pm

We can put actions in controller resources which are not logically mapped to any of CRUD operations e.g.
POST /device-management/{id}/alerts/{id}/resend

Above operation does not fall under CRUD.

Выше дан более интересный пример, когда операцию даже "разложить" не представляется возможным в силу описанных требований. Есть рассматривать коммент выше - то в описываемом случае нельзя включить status attribute в cart resource.

Всё просто:
Картинка с другого сайта.
25 сен 18, 22:49    [21686029]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 1714
Bsplesk
skyANA
Bsplesk, вот:

Rest. А как реализуются методы с логикой сложнее чем Добавить/Удалить ?


Что вот?
Компот.

Не понимаете, так это Ваши проблемы. Продолжайте и дальше постить глупые и никому не интересные картинки.
25 сен 18, 23:25    [21686053]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
Bsplesk,
у вас завышенные требования или старческое брюзжание?
Я не жду много от REST или там, "нормальной формы" в СУБД.
Они просто наводят порядок и логичность в своих областях.
REST наводит порядок в урл строке.
Нормальная форма наводит порядок в БД.
Так что узБагойтесь. Вы лучше порядок там и там всё равно не наведёте.
25 сен 18, 23:46    [21686078]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
love_bach
Member

Откуда:
Сообщений: 483
Bsplesk
Petro123
пропущено...

Построение урл для ресурса с REST API:
https://restfulapi.net/resource-naming/


offtop

REST - это круто :).
Простейший пример: есть клиент, есть карта, у карты есть pin и cvc, вещи эти отдельные, в одном объекте несовместимые, эти данные хранить нельзя они вычисляются при каждом запросе и передаются по разным каналам в одну операцию(вычисли и отправь - разделить на два метода нельзя, ибо хранить эти данные запрещено), при этом cvc динамический - id у него нет:

Как предлагается реализовывать соответствующий REST?

GET: /clients/{clientId}/cards/{maskedPan}/cvc ?
POST: /clients/{clientId}/cards/{maskedPan}/cvc ?

Всё, приехали - CRUD для описанной выше задачи не катит, он вообще мало для чего катит на самом деле

Что "новопридуманный" контроллер делать? - а по факту функцию, привет удаленный вызов процедур(RPC), и причем тут REST :) ?

controller

A controller resource models a procedural concept. Controller resources are like executable functions, with parameters and return values; inputs and outputs.

Use “verb” to denote controller archetype.

http://api.example.com/cart-management/users/{id}/cart/checkout
http://api.example.com/song-management/users/{id}/playlist/play
-------------------------------------------------

POST: /clients/{clientId}/cards/{maskedPan}/cvc/send ?
или
POST: /clients/{clientId}/cards/{maskedPan}/cvcSending/send ?


"Всё, приехали - CRUD для описанной выше задачи не катит, он вообще мало для чего катит на самом деле"

а где собственно задача?
26 сен 18, 05:41    [21686156]     Ответить | Цитировать Сообщить модератору
 Re: Описание REST API  [new]
Bsplesk
Member

Откуда:
Сообщений: 113
Petro123
Bsplesk,
старческое брюзжание?


Старческое .....
Не нервничайте, все хорошо. Нет у меня ни времени, ни желания наводить какие-то там порядки, тем более в REST сервисах порядок ограничен исключительно соглашением конкретного REST или не REST API (создать соглашение - это задача архитектора в случае отсутствия спецификации).
Единых спецификаций(как в случаях c SOAP/Odata/graphql...etc) для сервисов аля REST нет в принципе.
Каждый создает свою спецификацию в рамках своих задач вводя те или иные расширения, которые не вписываются в CRUD.
Убедится в этом легко, достаточно рассмотреть пару реальных API:
  • https://developer.atlassian.com/server/confluence/confluence-server-rest-api/
  • https://developer.paypal.com/docs/api/overview/#api-requests
  • https://developer.americanexpress.com/documentation#api-standard-practices
  • https://docs.gitlab.com/ee/api/lint.html (уже сбежали на graphql).
  • https://docs.aws.amazon.com/apigateway/api-reference/link-relation/model-generate-template/

    Пример с amazon API который использует: Link Relations:

    REST API Reference-->Link Relations-->model:generate-template

    model:generate-template

    Generates a sample mapping template that can be used to transform a payload into the structure of a model.

    amazon
    HTTP Request
    GET /restapis/<restapi_id>/models/<model_name>/default_template


    confluence

    Converting content
    Convert storage format to view format

    This example shows how to convert storage format to view format.

    confluence
    curl -u admin:admin -X POST -H 'Content-Type: application/json' -d'{"value":"<ac:structured-macro
    ac:name=\"cheese\" />","representation":"storage"}'
    "http://localhost:8080/confluence/rest/api/contentbody/convert/view" | python -mjson.tool


    paypal
    Executes a PayPal payment that the customer has approved. You can optionally update one or more transactions when you execute the payment.
    paypal
    POST: /v1/payments/payment/{payment_id}/execute


    p.s. говорят execute - это глагол .....
  • 26 сен 18, 12:29    [21686553]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38643
    Bsplesk
    Единых спецификаций(как в случаях c SOAP/Odata/graphql...etc) для сервисов аля REST нет в принципе.
    Каждый создает свою спецификацию в рамках своих задач вводя те или иные расширения, которые не вписываются в CRUD.
    да.
    Я же вам привёл пример с нормализацией.
    Коммунизма в конце концов)).
    Нет спецификации, но есть практика и стремления.
    Недаром есть термин rest, и потом добавили fullRest))).
    Вам прямо надо всех построить по спецификации)).
    Удачи!
    26 сен 18, 13:49    [21686698]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    maslinka
    Member

    Откуда: от верблюда
    Сообщений: 286
    в какой нотации описать лучше API?
    26 сен 18, 15:43    [21686913]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 26479
    maslinka,

    ReDoc: https://github.com/Rebilly/ReDoc
    26 сен 18, 16:07    [21686954]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 26479
    maslinka,

    там сразу и пример открыть можно: https://rebilly.github.io/ReDoc/
    26 сен 18, 16:15    [21686967]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Bsplesk
    Member

    Откуда:
    Сообщений: 113
    maslinka
    в какой нотации описать лучше API?


    maslinka,

    Спецификации (не инструменты отображения или создания):
    В зависимости от задач:
  • дубовых синхронных API: OpenAPI2/3 (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md)
  • дубовых асинхронных (WebSocket/HTTP2 в вебе): OpenAPI3(https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md) или asyncapi (https://www.asyncapi.com/v1/guide/)

    гибких (аля sql - запрос):
    Odatav4: https://www.odata.org/documentation/
    graphql: http://facebook.github.io/graphql/

    ReDoc - хорош для генерации документации по готовому контракту(спецификации OpenAPI 2/3).

    Ну и классика: https://www.w3.org/TR/wsdl/ (но это XML подобное, не модное).
  • 26 сен 18, 17:57    [21687199]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Bsplesk
    Member

    Откуда:
    Сообщений: 113
    Предварительно следует определить языки программирования на котором будет разработано API, а также тех кто будет это api использовать. Также следует ознакомится с поддержкой в конкретном языке (это прямо влияет на скорость разработки) данной спецификации (возможность генерации кода по контракту и наоборот по коду контракт ...).
    Хотя killer feature REST подобных API, что с ними легко начать работать на любом языке, в котором есть поддержка http, просто прочитав соглашение, которое может сгенерировать тотже ReDoc.
    26 сен 18, 18:07    [21687216]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Red1zko
    Member

    Откуда:
    Сообщений: 2
    Уж не знаю на сколько поможет наконец закончить рассуждения в этом топике моя личная практика, но на данный момент я делаю так:
    1. Получаю задачу на разработку (роль архитектор/аналитик тут не причем)
    2. Собираю бизнес требования к задаче, формирую простой документ где описываются все потребности бизнеса
    3. Исходя из получившейся доки формирую ТЗ на разработку
    и выглядит это следующим образом:
    - собираю объектную модель в ЕА
    - для разработчика модель данных в ЕА (очень удобно, на основании нее можно получить кучу sql для разворачивания практически любой БД особо не вникая в тонкости)
    - определяюсь с контрактом для API (лучшее что нашел - для команды с развязанными руками это swagger hub, для команды которой приходиться постоянно выпрашивать это ready api smart bear)
    - на основании контракта поднимаю mock сервис с простейшей логикой
    - логику работы внутри API описываю с помощью activity диаграммы в ЕА
    - логику работы между front и back описываю с помощью activity диаграммы в ЕА
    - прецеденты использования через use case диаграммы в ЕА
    - интеграционные взаимодействия через componet model диаграммы в ЕА (микросервисы родненькие)
    - описание протоколов, серверов и что где должно крутиться через deployment диаграмму.
    Ну и конечно венцом всего этого является автоматическая генерация документа в ЕА (правда посидел настраивая шаблон)
    27 сен 18, 16:28    [21688354]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38643
    Red1zko
    Уж не знаю на сколько поможет
    не поможет, т.к. это обо всём процессе производства ПО "человеком оркестром".
    27 сен 18, 16:36    [21688367]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Red1zko
    Member

    Откуда:
    Сообщений: 2
    Petro123, ну можно же разделить этот процесс по ролям и так будет даже быстрее(правда не проще, но это уже на вкус и цвет)
    27 сен 18, 16:53    [21688380]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    alex55555
    Member [заблокирован]

    Откуда:
    Сообщений: 2129
    Red1zko
    1. Получаю задачу на разработку (роль архитектор/аналитик тут не причем)

    Очень даже "при чём".
    Red1zko
    собираю объектную модель в ЕА
    - для разработчика модель данных в ЕА ...
    - определяюсь с контрактом для API ...
    - на основании контракта поднимаю mock сервис с простейшей логикой
    - логику работы внутри API описываю с помощью activity диаграммы в ЕА
    - логику работы между front и back описываю с помощью activity диаграммы в ЕА
    ...
    - интеграционные взаимодействия через componet model диаграммы в ЕА...
    - описание протоколов, серверов и что где должно крутиться через deployment диаграмму..

    Вот так примерно уг и получается. Садят "аналитика" на некую задачу, а этот перец ни ухом ни рылом в архитектуре, но очень верит в себя и страждет нарисовать шедевр. Ну и конечно, в шедевре ничего не получится, если "аналитик" сам не поковыряется абсолютно во всём. Поэтому перца тянет на ... ну в общем на абсолютно всё. Он даже слышал, что код ему писать не надо, но ведь шедевр пропадёт! И потому он как минимум на SQL наваяет какую-нибудь элементарную хрень, которой потом будет в нос всем тыкать - вот, смотри как у меня просто, а ты что наворотил?! Ну и разумеется, как же без деплоймента! Ога, оналитег и про это абсолютно всё-всё знает! И очень хочет это всем доказать. Ну и в общем рожает этакого ублюдка, которого в страшном сне не увидишь, но автор с пеной у рта всем будет доказывать - это шедевр! Осталось сказать "я так вижу", но оналитег знаком с соответствующим произведением, а потому выбирает немного другие фразы. Но суть та же.

    В целом те придурки, которые наняли, а самое главное - дали вот так безобразничать этому оналитегу, получают гарантированное уг, от него все плюются, но что толку? Придурки знают, что надо через аналитика работать. Но как - они не знают. Ну и отдают инициативу самому крикливому. И когда таким крикливым оказывается оналитег - ну в общем картина Репина "приплыли". Хотя если таким крикливым окажется программист, то картина тоже получается ... может и не Репина, но какой-нибудь Савраска в ней обязательно присутствует и тянет свою телегу, и обязательно поперёк МКАД-а. А чо, это же эффективно!
    27 сен 18, 20:01    [21688514]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    maslinka
    Member

    Откуда: от верблюда
    Сообщений: 286
    Red1zko
    Уж не знаю на сколько поможет наконец закончить рассуждения в этом топике моя личная практика, но на данный момент я делаю так:
    1. Получаю задачу на разработку (роль архитектор/аналитик тут не причем)
    2. Собираю бизнес требования к задаче, формирую простой документ где описываются все потребности бизнеса
    3. Исходя из получившейся доки формирую ТЗ на разработку
    и выглядит это следующим образом:
    - собираю объектную модель в ЕА
    - для разработчика модель данных в ЕА (очень удобно, на основании нее можно получить кучу sql для разворачивания практически любой БД особо не вникая в тонкости)
    - определяюсь с контрактом для API (лучшее что нашел - для команды с развязанными руками это swagger hub, для команды которой приходиться постоянно выпрашивать это ready api smart bear)
    - на основании контракта поднимаю mock сервис с простейшей логикой
    - логику работы внутри API описываю с помощью activity диаграммы в ЕА
    - логику работы между front и back описываю с помощью activity диаграммы в ЕА
    - прецеденты использования через use case диаграммы в ЕА
    - интеграционные взаимодействия через componet model диаграммы в ЕА (микросервисы родненькие)
    - описание протоколов, серверов и что где должно крутиться через deployment диаграмму.
    Ну и конечно венцом всего этого является автоматическая генерация документа в ЕА (правда посидел настраивая шаблон)

    мы реализуем примерно это же)
    2 окт 18, 09:26    [21692211]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    Serguei
    Member

    Откуда: Papua New Guinea
    Сообщений: 647
    Red1zko
    - для разработчика модель данных в ЕА (очень удобно, на основании нее можно получить кучу sql для разворачивания практически любой БД особо не вникая в тонкости)


    Можно попросить вас уточнить вот этот момент. Вы из ЕА генерируете скрипты на создание/изменение структуры БД? Что то я отстал от жизни, если там такое возможно.
    2 окт 18, 13:43    [21692590]     Ответить | Цитировать Сообщить модератору
     Re: Описание REST API  [new]
    maslinka
    Member

    Откуда: от верблюда
    Сообщений: 286
    Red1zko
    получить кучу sql для разворачивания практически любой БД особо не вникая в тонкости)

    фраза противоречивая. )
    2 окт 18, 14:40    [21692720]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2      [все]
    Все форумы / Разработка информационных систем Ответить