Да, прежде чем использовать REST, надо понять зачем это. Серебряной пули нет. Но если уж говорит что у вас есть REST API, то надо чтобы оно было REST, а не помесью непонятно чего с непонятно чем.
Не совсем про микросервисы, а про REST и «чистоту расы», коммент.
Если есть необходимость выполнения бизнес-действий (а они как правило есть) над данными (которыми оперирует REST), то есть смысл вводить понятие задач. Задачами являются бизнес-действия (возможно длительные), которые представлены в REST существительными, а не глаголами. Т.е. не надо в URL пихать глаголы.
Например:
Создаем задачу:
POST /api/v1/tickets/{ticketid}/tasks
{'action': 'migrate', ...params}
В ответ получаем модель задачи и если ее статус не завершен, то через некоторое время делаем так:
GET /api/v1/tickets/{ticketid}/tasks/{taskid}
Не могут! Не все могут. Потому что никто не считает, что он не может спланировать заранее что будет потом. Всем кажется что все хорошо. «Я могу. У меня получится.» А получается не у всех.
Не знаю как у вас, но когда я учился было много задач, где из такста надо было составить уравнение и решить его. И ситуации в этих задачах были вполне жизненные.
Коллега когда-то подсказал как объяснить, зачем нужна геометрия.
Вот собрались вы обои переклеить в комнате и не знаете сколько рулонов брать. Но вы знаете что ваши соседи внизу (или сверху — не важно) неделю назад делали ремонт в такой же комнате.
— Сколько вы рулонов покупали? — спрашиваете у них.
— 10 — отвечают они.
— Хорошо! — думаете вы, и покупаете 10 рулонов. Затем клеите обои и 3 рулона остается. Непоняточка. Идете к соседям.
— Я купил 10 рулонов как вы и говорили, но у меня 3 осталось. Как так?
— Так и у нас 3 осталось.
А вот если бы вы могли посчитать площадь стен до покупки обоев, то не надо было бы гадать.
.net core, .net framework — это то, где приложение исполняется.
.net standard — это то, «на чем можно писать» чтобы можно было исполняться на любом .net, поддерживающим этот стандарт.
т.е. на .net standard нельзя написать приложение. можно написать либу, которую можно использовать как в мобильном приложении (xamarin), так и на бекенде (asp.net [core])
WPF не плохой вариант. UWP (после потери Mobile не такой уж и U) тоже хорошо, но только под 10. WinForms — наверно уже нет (мое личное имхо). Недавно был анонс про React Native for Windows — тоже наверно забавно.
Скажите, а с какой практической целью вы добавляете Linux машины в AD?
Групповых политик нет — т.е. управлять данной машиной на ровне с Windows не получится.
Аутентификация на самой машине — ну Ok. Можете ли вы прозрачно аутентифицироваться на других машинах (на самом деле не знаю и хочу узнать)? Имеете ли доступ к DFS?
Я не любитель продукции Apple, но мне кажется и в Apple буках, и в не-Apple буках, для комфортной работы, крышку надо открыть на более чем 90*. Т.е. рекомендация соблюдать угол менее 90* звучит как — купил бук Apple => страдай.
С Linux всегда всё не просто. Не скажу что это плохо, просто там все по другому. И когда люди привыкают к этому другому, то Windows им кажется «по другому».
Первый раз слышу о подобном. Если не секрет, то кто именно это делать не умеет? Что-бы на будущее знать.
PS: ESP (50 IP) не все умеют прокидывать внутрь сети, но чтобы наружу кого-то не пускать…
То что написано в статье, это потрясающе. Но с чего вы взяли что openvnp это дефакто стандарт? Чтобы соединение было установлено требуется стороннее по на клиенте. Я бы сказал, openvnp это хорошая альтернатива стандартным l2tp и ikev2.
Не зная где находится источник света, кратеры можно перепутать с «бугорками».
А вот если сначала посмотреть на сам луноход, то можно понять где источник света. И сейчас кратеры уже не кажутся бугорками.
В таком случае входные данные должны передаваться не массивом, а генератором. Но по условию задачи это не так.
Можно даже обойтись без массива интервалов и сразу аккумулировать результат, храня лишь данные последнего интервала.
Можно и так:
Если есть необходимость выполнения бизнес-действий (а они как правило есть) над данными (которыми оперирует REST), то есть смысл вводить понятие задач. Задачами являются бизнес-действия (возможно длительные), которые представлены в REST существительными, а не глаголами. Т.е. не надо в URL пихать глаголы.
Например:
Создаем задачу:
POST /api/v1/tickets/{ticketid}/tasks
{'action': 'migrate', ...params}
В ответ получаем модель задачи и если ее статус не завершен, то через некоторое время делаем так:
GET /api/v1/tickets/{ticketid}/tasks/{taskid}
Можем отменить задачу
DELETE /api/v1/tickets/{ticketid}/tasks/{taskid}
Если выполнение задачи еще не началось, то можно разрешить изменение ее параметров
PUT /api/v1/tickets/{ticketid}/tasks/{taskid}
Итого: Можно и REST сохранить, и бизнес-действия выполнить, и за чистоту расы не бояться.
Вот собрались вы обои переклеить в комнате и не знаете сколько рулонов брать. Но вы знаете что ваши соседи внизу (или сверху — не важно) неделю назад делали ремонт в такой же комнате.
— Сколько вы рулонов покупали? — спрашиваете у них.
— 10 — отвечают они.
— Хорошо! — думаете вы, и покупаете 10 рулонов. Затем клеите обои и 3 рулона остается. Непоняточка. Идете к соседям.
— Я купил 10 рулонов как вы и говорили, но у меня 3 осталось. Как так?
— Так и у нас 3 осталось.
А вот если бы вы могли посчитать площадь стен до покупки обоев, то не надо было бы гадать.
.net standard — это то, «на чем можно писать» чтобы можно было исполняться на любом .net, поддерживающим этот стандарт.
т.е. на .net standard нельзя написать приложение. можно написать либу, которую можно использовать как в мобильном приложении (xamarin), так и на бекенде (asp.net [core])
Групповых политик нет — т.е. управлять данной машиной на ровне с Windows не получится.
Аутентификация на самой машине — ну Ok. Можете ли вы прозрачно аутентифицироваться на других машинах (на самом деле не знаю и хочу узнать)? Имеете ли доступ к DFS?
PS: ESP (50 IP) не все умеют прокидывать внутрь сети, но чтобы наружу кого-то не пускать…
То что написано в статье, это потрясающе. Но с чего вы взяли что openvnp это дефакто стандарт? Чтобы соединение было установлено требуется стороннее по на клиенте. Я бы сказал, openvnp это хорошая альтернатива стандартным l2tp и ikev2.
А вот если сначала посмотреть на сам луноход, то можно понять где источник света. И сейчас кратеры уже не кажутся бугорками.