BG Development


Страници: (3) [1] 2 3   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> SPA и Spring boot
crazy_dog
Публикувано на: 18-06-2020, 12:08
Quote Post



Име:
Група: Потребител
Ранг: Активен

Мнения: 162
Регистриран на: 23.02.12



Здравейте!
Налага ми се да започна проект който ще е Single page application със Spring boot back-end. Нямам много опит с SPA, затова реших да попитам за някои неща.
Като front-end мисля да използвам vuejs. Сега съм в процес на разучаване, но ми допада повече от reactjs и angular. Пък и се учи по-лесно. icon_smile.gif
Първият казус пред който умувам е структурата на проекта. Дали front-end и back-end да са в един проект или да са разделени в различни проекти.
Най-логично, поне за мен, е да са в различни проекти. Но чета, че някъде ги правят и на едно. Не мога да преценя какви са предимствата и недостатъците от това. (проекта няма да го пиша само аз, ще участват още хора)
Другият казос е изцяло програмен. Мисля да използват restful архитектура (въпреки, че сега силно се препоръчва GraphQL пред rest, но нямам време да го уча сега).
Та, докато си тествам разни примери, си направих една по-сложна форма. Примерно с 10 dropdown-а. Всеки dropdown си зарежда списък с данни.
Ако спазвам restful принципите, това са 10 заявки. Не е много добре от гледна точка на бързодействието.
Затова си направих един end-point който връща всичките данни необходими за populate-ването на формата в една заявка.
Всичко си работи добре, но пък не спазвам принципите на restful за унифициране на ресурсите. Не знам какви са добрите практики за този проблем.
Последният ми казус е свързан с POST и PUT. Според restful спецификацията, POST се използва само да се създават обекти. А със PUT се обновяват съществуващи такива. Като PUT обновява целият обект, докато PATCH може да обновиш само част от обекта.
Не виждам проблем да се използва POST за обновяване на обект (разбира се, трябва да се добави идентификатора на обект).
Та по запознаните да кажат има ли смисъл за имплементиране на PUT (евентуално PATCH) и какви са предимствата от това.

Поздрави
PMEmail Poster
Top
bvbfan
Публикувано на: 18-06-2020, 13:37
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3789
Регистриран на: 08.12.13



Едно основно пояснение, дали rest или каквото и да е, обекти там няма. Това са данни, наричани още entity.

https://restfulapi.net/rest-put-vs-post/

QUOTE
PUT method is idempotent. So if you send retry a request multiple times, that should be equivalent to single request modification.
POST is NOT idempotent. So if you retry the request N times, you will end up having N resources with N different URIs created on server.


--------------------
QUOTE (Bender @ 23-04-2015, 19:11)
Xamarin: ЛАПАЙ!
Ти: Добре...
PMEmail Poster
Top
thrawn
Публикувано на: 19-06-2020, 05:35
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2930
Регистриран на: 17.01.17



Няма такова нещо като restful спецификации. Rest е архитектура а restful е rest архитектура върху http.

Идеята на употребата на различни http методи за CRUD операции върху един ресурс е да запазиш консистенцията на endpoint-ите. /api/user/{id} да речем може да се ползва и за четирите основни операции като разлика от кливланд така гледна точка ще е http методът @GET за четене, @POST за създаване, @PUT за ъпдейт и съответно @DELETE за триене. Практически няма никакво значение дали ще ползваш PUT и POST (че и DELETE) за модификация на ресурс, но така API то става по-просто (ако ползваш едни и същи web методи щв ти трябват различни url и ьа ендпоинти) и с него се работи по-интуитивно.

Не прави извличането на различните ресурси с една заявка. Практически това е безсмислено и няма да получиш никаква оптимизация от това. Дали заявката е една или са 10 е все тая (виж ако станат наистина много можеш да се замислиш) но ако направиш обща точка за достъп то кодът ще стане труден за поддръжка.
PMEmail Poster
Top
thrawn
Публикувано на: 19-06-2020, 06:20
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2930
Регистриран на: 17.01.17



Въпросът с пакетирането обаче е доста по-сериозен.
Като цяло, подобна архитектура налага разделяне на бизнес логиката от изгледът. А това предполага пакетирането на отделните части в различни файлове. Но от тук ти почват проблемите.
Първо, spring boot си вдига сървър, което значи, че ще имаш отделни сървъри за всяка част на приложението което технически е ОК но пък това отваря още проблеми, като например автентикацията на потребителите.

Или казано по-просто трябва да разделиш нещата, но е много по-лесно да ги оставиш в общ пакет (за да работят на един сървър) и да си спестиш доста работа.



PMEmail Poster
Top
Gamma Goblin
Публикувано на: 19-06-2020, 08:11
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3856
Регистриран на: 21.02.18



разликата междy ПОСТ и ПУТ е, че ПОСТ всеки път създава нов ресурс, а ПУТ трябва да бъде idempotent.

Тоест ако навикаш ПОСТ 3 пъти, трябва да свършиш с 3 различни ресурса, докато ако навикаш ПЪТ 3 пъти - само с 1. ТОва е много важно когато тръгнеш да ги имплементираш, и още по-важно за потребителите на апи-то.


Като цяло РЕСТ-а е минало. Бил е революция в началото на cloud computing-a, но в момента има много по-добри решения - grpc, graphql. Най-голямата грешка на реста е че смесва транспортния протокол (HTTP) с application protocol-a. Не всичко може да се изрази (по разумен и удобен начин) с GET/POST/PUT/DELETE.

За вебсайт е ОК, но за *приложение* REST-a не става, просто му мина времето.


--------------------
https://ncase.me/trust-bg/
---
Misanthropy is the general hatred, dislike, distrust or contempt of the human species or human nature. A misanthrope or misanthropist is someone who holds such views or feelings.
---
INTJ’s are good at being very good at everything
---
"Чувството за вина дето искаш да ни го вмениш, може да си го навиеш на руло и да си го пъхнеш отзад." - stewe
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 19-06-2020, 09:09
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2930
Регистриран на: 17.01.17



rest няма нищо общо с транспортния протокол - това в просто название на клиент - сървър архитектура.
Restful Е реализация на rest архитектура ВЪРХУ http.
PMEmail Poster
Top
Gamma Goblin
Публикувано на: 19-06-2020, 09:17
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3856
Регистриран на: 21.02.18



аха, и ХТТП е транспортния протокол icon_smile.gif щом апа почне да зависи на статус ХТТП статус кодове, хедъри, и глаголи, значи си е е*ало века

въпреки че grapgql обикновено работи върху хттп, в него тия неща не са expose-нати, ако искаш може да го имплементираш и върху SMTP и клиента няма да види разлика в АПИ-то

Това мнение е било редактирано от Gamma Goblin на 19-06-2020, 09:19


--------------------
https://ncase.me/trust-bg/
---
Misanthropy is the general hatred, dislike, distrust or contempt of the human species or human nature. A misanthrope or misanthropist is someone who holds such views or feelings.
---
INTJ’s are good at being very good at everything
---
"Чувството за вина дето искаш да ни го вмениш, може да си го навиеш на руло и да си го пъхнеш отзад." - stewe
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 19-06-2020, 09:58
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2930
Регистриран на: 17.01.17



Rest е архитектурен шаблон описващ най-общо stateles архитектура клиент-сървър. С други думи, дори http E rest. Всичко което описвате като модерни заместители са просто имплементации - демек някакъв framework който налага освен архитектура и комуникационен протокол.

Дали са по-хубави или не е безсмислено да се спори защото е несериозно да сравняваш архитектуа с framework (същия цирк го имаше преди време с rest vs soap).

Самите ПРЕПОРЪКИ за реализация на rest върху http (restful) по никакъв начин не налагат никаква употреба на каквото и да било от http спецификациите, освен адресирането на ресурсите (все пак, цялата еидея е да се ползват стандартни клиенти и сървъри). От тук на татък, целия комуникационен протокол е в ръцете на разработчикът (затова и се появяват готови рамки предлагащи някакви имплементации).
Са, друг е въпроса, че масово "капацитети" почват да обясняват кое как било според спецификациите на http и как видиш ли трябвало да следваш същата спецификация и в restful. Да ама не.

Това мнение е било редактирано от thrawn на 19-06-2020, 09:59
PMEmail Poster
Top
JanBirdX
Публикувано на: 19-06-2020, 10:21
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1731
Регистриран на: 21.02.05



QUOTE (thrawn @ 19-06-2020, 09:58)
Rest е архитектурен шаблон описващ най-общо stateles архитектура клиент-сървър. С други думи, дори http E rest...

Ем така е! Всичко е рест. Амъ си и вярваш. Всичко е DCOM.
PMEmail Poster
Top
thrawn
Публикувано на: 19-06-2020, 11:13
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2930
Регистриран на: 17.01.17



Ако смяташ да ми опонираш, поне се пробвай да използваш смислени аргументи.
Емементарна проверка в гугъл показва, че съм прав.
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (3) [1] 2 3  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0