Pull to refresh

Comments 8

ага, я как раз вчера на это набрел. И там еще примеры провайдеров, например для регэкспов.
Вообще самое важное это по-моему определиться, будет ли это работать для RESTful сервисов или нет. Ведь у этих сервисов нет описания (WADL не в счет), и единственный способ, которые мне представляется возможным, это использовать линки которые модель HATEOAS поставляет. Что думаете?
Дим, я если честно в этой области не очень. Глянул про HATEOAS, но понял очень условно. Посоветуй, чего почитать по теме. :)
При таком раскладе без доступа к базе или к интернету, код даже откомпилировать не получится, верно? Что будет если схема базы изменится? В частности оно же не сможет при инкрементальном билде перестроить сборку с генеренными типами?

Хотя фича прикольная. По крайней мере это менее убого чем генерация C#-кода с последующей компиляцией, как это сделано для WSDL.
да, при неправильном коннекте (что к сервису, что к базе) ругается компилятор, в чем успел уже самолично убедиться. И да, это конечно прикольно выглядит именно в режиме обзервинга, т.е., вот есть у меня ссылочка на сервисе, дай-ка я с помощью Interactive поброжу-погляжу, чего там есть. Так очень круто. Как в реальном проекте это применимо, не знаю.
REST in Practice, для начала. Если коротко, то суть HATEOAS в том что у нас нет никакой схемы, т.к. сервис может постоянно меняться при этом не публикуя никакой машиночитабельный контракт. А HATEOAS говори, что на каждый вызов REST-сервися мы можем возвращать вместе с результатами запроса набор ссылок (например atom:link) которые указывают на все возможные действия, которые потребитель сервиса может совершить в данной точке.
Sign up to leave a comment.

Articles