Епизод 110 – част 2 – Правилният начин да правим REST

Разговор на тема “Правилният начин да правим REST”

The Good Way to REST: Introduction
The Good Way to REST: Core Values And Mechanics
The Good Way To REST: Road to Maturity

Директен линк към част 2 (mp3)

Tags:
| май 14th, 2019 | Posted in Uncategorized |

5 коментара to “Епизод 110 – част 2 – Правилният начин да правим REST”

  1. stankov Austria Google Chrome Linux Says:

    Браво, много добра дискусия!

    Относно 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

  2. PaperNick Bulgaria Mozilla Firefox Ubuntu Linux Says:

    За PATCH не съм много сигурен, че разбрах аргумента със статично типизираните езици (около 13:00 мин се говори за него). Защо е нужно да се прави някакъв обект при положение, че той вече съществува? Не може ли просто да си го взема и да го обновя с това което ми идва от request-а? Или .NET-а те задължава да си го направиш наново поради някаква причина?

  3. PaperNick Bulgaria Mozilla Firefox Ubuntu Linux Says:

    Също, ако искам да променя само статуса на някакъв голям Order, защо да ползвам PUT? Аз виждам няколко проблема тук. Ако не си направя пресен GET на ресурса, не мога да си гарантирам, че обновявам с последните неща. Другото, е че размятам разна информацията по мрежата, която въобще не ми трябва и ако ресурса е по-голям, ще ми трябва и повече bandwitdh.

  4. Stilgar Bulgaria Google Chrome Windows Says:

    Уф не съм ги видял тея коментари. С PATCH проблемът е как ще моделираш самия request. Аз обичам да приема статично типизиран обект, вместо key/value pairs.

  5. PaperNick Bulgaria Mozilla Firefox Ubuntu Linux Says:

    И аз малко със закъснение отговарям.

    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-а става на ръка?

Leave a Reply