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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Откуда: от верблюда
Сообщений: 283
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
Сообщений: 619
maslinka
надо в enterprise architect описать rest api и как из интерфейса (формы) параметры передаются rest api.


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

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


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

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

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


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


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

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

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

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

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

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

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

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

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

Откуда:
Сообщений: 106
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)
Сообщений: 37116
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

Откуда:
Сообщений: 106
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)
Сообщений: 37116
Bsplesk
REST - это круто :).
Простейший пример: есть клиент, есть карта, у карты есть pin и cvc

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

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

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

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

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

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

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

Откуда:
Сообщений: 106
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

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

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


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

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

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

Откуда:
Сообщений: 424
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Разработка информационных систем Ответить