SPA и Spring boot

Здравейте!
Налага ми се да започна проект който ще е Single page application със Spring boot back-end. Нямам много опит с SPA, затова реших да попитам за някои неща.
Като front-end мисля да използвам vuejs. Сега съм в процес на разучаване, но ми допада повече от reactjs и angular. Пък и се учи по-лесно.
Първият казус пред който умувам е структурата на проекта. Дали 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) и какви са предимствата от това.

Поздрави

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

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

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

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

Не прави извличането на различните ресурси с една заявка. Практически това е безсмислено и няма да получиш никаква оптимизация от това. Дали заявката е една или са 10 е все тая (виж ако станат наистина много можеш да се замислиш) но ако направиш обща точка за достъп то кодът ще стане труден за поддръжка.

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

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

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

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


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

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

rest няма нищо общо с транспортния протокол - това в просто название на клиент - сървър архитектура.
Restful Е реализация на rest архитектура ВЪРХУ http.

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

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

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

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

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

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

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

Ем така е! Всичко е рест. Амъ си и вярваш. Всичко е DCOM.

Ако смяташ да ми опонираш, поне се пробвай да използваш смислени аргументи.
Емементарна проверка в гугъл показва, че съм прав.