Относно HATEOAS съм много съгласен. Вълнуваща идея, но засега не съм вдиял жив екземпляр. За мен сновният й проблем е, че клиентът или трябва да е прекалено неспецифичен (като браузъра, който отваря всичко), или изключително интелигентен, така че да може да борави с динамични rel-s без човешка намеса. А вторият случай е много релевантен, API -тата са все пак направени за ползване от машини, не от хора.
Въпреки това е важно да не се забравя, че идеята на API-то е да има хлабава сдвоеност – ако контролираш сам и фронтенда и бекенда, тогава е все тая колко грозно не-рест API си си направил за лично ползване.
И тъй като REST е някаква странна релеигия, цитат (релевантен и за GrapphQL) от писателят на евангелието й:
„fixing the data model between client and server so that your own clients interact more efficiently with your own servers isn’t what REST is about, nor is it an API.“ https://twitter.com/fielding/status/1124089080688644096
За PATCH не съм много сигурен, че разбрах аргумента със статично типизираните езици (около 13:00 мин се говори за него). Защо е нужно да се прави някакъв обект при положение, че той вече съществува? Не може ли просто да си го взема и да го обновя с това което ми идва от request-а? Или .NET-а те задължава да си го направиш наново поради някаква причина?
Също, ако искам да променя само статуса на някакъв голям Order, защо да ползвам PUT? Аз виждам няколко проблема тук. Ако не си направя пресен GET на ресурса, не мога да си гарантирам, че обновявам с последните неща. Другото, е че размятам разна информацията по мрежата, която въобще не ми трябва и ако ресурса е по-голям, ще ми трябва и повече bandwitdh.
Уф не съм ги видял тея коментари. С PATCH проблемът е как ще моделираш самия request. Аз обичам да приема статично типизиран обект, вместо key/value pairs.
PaperNick: „Не може ли просто да си го взема и да го обновя с това което ми идва от request-а?“
Може би трябваше да уточня за кой PATCH точно говоря – JSON Merge Patch: https://tools.ietf.org/html/rfc7396
В повечето случаи (по-прости APIs), на мен лично този стандарт ми върши работа и наподобява доста на PUT с малки изключения, като манипулиране на масиви, set-ване на null и т.н.
Ако говорим за JSON Patch: https://tools.ietf.org/html/rfc6902 http://jsonpatch.com/
съм съгласен, че ще трябва повече работа по изготвянето на request-а, понеже се изисква специална структура по която да бъдат описани операциите.
Та в тази връзка, .NET не предоставя ли лесен начин за имплементирането на един от двата PATCH-а out of the box? Или всичкото parse-ване на request-а става на ръка?
май 21st, 2019 at 00:46
Браво, много добра дискусия!
Относно HATEOAS съм много съгласен. Вълнуваща идея, но засега не съм вдиял жив екземпляр. За мен сновният й проблем е, че клиентът или трябва да е прекалено неспецифичен (като браузъра, който отваря всичко), или изключително интелигентен, така че да може да борави с динамични rel-s без човешка намеса. А вторият случай е много релевантен, API -тата са все пак направени за ползване от машини, не от хора.
Въпреки това е важно да не се забравя, че идеята на API-то е да има хлабава сдвоеност – ако контролираш сам и фронтенда и бекенда, тогава е все тая колко грозно не-рест API си си направил за лично ползване.
И тъй като REST е някаква странна релеигия, цитат (релевантен и за GrapphQL) от писателят на евангелието й:
„fixing the data model between client and server so that your own clients interact more efficiently with your own servers isn’t what REST is about, nor is it an API.“ https://twitter.com/fielding/status/1124089080688644096
май 27th, 2019 at 10:34
За PATCH не съм много сигурен, че разбрах аргумента със статично типизираните езици (около 13:00 мин се говори за него). Защо е нужно да се прави някакъв обект при положение, че той вече съществува? Не може ли просто да си го взема и да го обновя с това което ми идва от request-а? Или .NET-а те задължава да си го направиш наново поради някаква причина?
май 27th, 2019 at 10:47
Също, ако искам да променя само статуса на някакъв голям Order, защо да ползвам PUT? Аз виждам няколко проблема тук. Ако не си направя пресен GET на ресурса, не мога да си гарантирам, че обновявам с последните неща. Другото, е че размятам разна информацията по мрежата, която въобще не ми трябва и ако ресурса е по-голям, ще ми трябва и повече bandwitdh.
юли 5th, 2019 at 11:34
Уф не съм ги видял тея коментари. С PATCH проблемът е как ще моделираш самия request. Аз обичам да приема статично типизиран обект, вместо key/value pairs.
юли 21st, 2019 at 21:16
И аз малко със закъснение отговарям.
PaperNick: „Не може ли просто да си го взема и да го обновя с това което ми идва от request-а?“
Може би трябваше да уточня за кой PATCH точно говоря – JSON Merge Patch:
https://tools.ietf.org/html/rfc7396
В повечето случаи (по-прости APIs), на мен лично този стандарт ми върши работа и наподобява доста на PUT с малки изключения, като манипулиране на масиви, set-ване на null и т.н.
Ако говорим за JSON Patch:
https://tools.ietf.org/html/rfc6902
http://jsonpatch.com/
съм съгласен, че ще трябва повече работа по изготвянето на request-а, понеже се изисква специална структура по която да бъдат описани операциите.
Та в тази връзка, .NET не предоставя ли лесен начин за имплементирането на един от двата PATCH-а out of the box? Или всичкото parse-ване на request-а става на ръка?
октомври 17th, 2019 at 16:01
Patch в ASP.Net Core -> https://docs.microsoft.com/en-us/aspnet/core/web-api/jsonpatch?view=aspnetcore-3.0
октомври 17th, 2019 at 23:57
Брей това са го измислили по-умно отколкото предполагах. И пак е грозно.