Оно выглядит именно так, как должно выглядеть на этой платформе — поэтому оно и нравится всем. И работает оно достаточно шустро.
Кстати, Viber под windowsphone в этом плане очень плох и не доработан — когда активировал desktop приложение, пуш уведомление с кодом активации пришло, а вот открыться не смогло, и те же стикеры отсутствуют, да и так по мелочи, звонки так вообще толком не работали у меня. Думаю, что приложение было сделано для галочки и пока объем пользователей не заставляет делать версию лучше.
Зато, в отличии от whatsapp у Viber есть desktop клиент.
Скорее суть в том, что ошибка может воспроизводиться именно при определенном кеше, т.е. ошибка в формировании\поддержании состояния в памяти между запросами, а это значит, что для ее воспроизведения недостаточно знать только состояния базы и запущенного приложения — надо будет прогнать всю цепочку запросов, что бы понять какой из них привел к ошибке\нарушению состояния.
Хотя по факту, REST просто выглядит как stateless протокол для клиента. В реализации он может быть не менее statefull чем и остальные. Вообще если сравнивать stateless протокол и statefull протокол — то надо смотреть не на реализацию, а на то, как он выглядит для клиента, ведь это stateless\full именно для клиента, а не для реализации.
Думаю это лишь частный пример. У меня обычная MasterCard (с тарифом 650 рублей), на остаток на счете каждый месяц мне начисляют денежку (вроде бы 3.5% готовых, хотя написано что сейчас уже 4.5%), а так же на ней же есть cash-back в виде 1% при сумме покупок от 3 000 (следующий шаг уже слишком велик, что бы его приводить ;), который правда надо подключать.
Нет, я про другое, я про старт самого приложения, если оно запущено в режиме x64, то загрузить в него x86 библиотеку уже не получится. При этом легкого способа указать, что твое приложение изначально надо запускать в x86 нельзя (ну кроме как пересобрать в x86).
На вопрос, а зачем же тогда основное приложение в AnyCPU, а не в x86, раз известна такая зависимость — она как раз неизвестна, приложение подгружает плагины, которые могут быть зависимы уже от либы, которая есть только в x86.
по крайней мере тогда, я наткнулся на вот эту статью(как то там категорично говорилось, что AnyCPU запускается как x64), и решил что в моем случае быстрее было собрать основное приложение еще и под x86, и идти дальше.
Но ведь изначальный выбор внешней библиотеки будет зависеть от того, под какую платформу собран запускающийся исполняемый файл? Точнее под какой платформой он стартовал.
У меня была следующая проблема, была внешняя библиотека (написанная даже не под .NET) под x86. Она подключалась к исполняемому файлу, который был собран как AnyCPU. Все это хорошо работает на 32 разрядной системе, но при попытке запуска на 64-разрядной, приложение запускается (т.к. оно AnyCPU) в x64, и соответственно оно не может загрузить нужную библиотеку. Скорее всего я не очень долго искал (как AnyCPU приложение запустить в режиме x86 на 64-разрядной системе), но что то мне подсказывает, что это должно как то настраиваться?
твиттер — это микро блог, почти как пейджер, только без оператора (а пейджер он застал), среди множества сайтов достаточно легко его освоить (запутаться слегка потом можно правда), к тому же, если ему помогала жена.
Опыт и прочтение книг — это разные вещи, суть моего вопроса как раз и сводилась к тому, что мне интересен реальный опыт использования организации именно таких ссылок (когда кроме идентификатора объекта передается еще и как его получить), и какие преимущества это давало в работе, по сравнению с тем, когда передается просто идентификатор связанного объекта.
Т.е. это получается, что некое описание схемы объекта user (части его схемы), передается сразу вместе с его данными. Хотя кажется, что схема объекта и сами данные для него — разные вещи. Когда это реально необходимо делать?
описывает, что у пользователя есть группы, и их можно получить вот так то. Т.е. это некая мета информация об объекте.
Если я работаю с пользователем и знаю что он может быть в группах, мне эта информация не на столько важна (я скорее всего уже знаю как получить группы пользователя). Или возможно эта информация есть в описании документации. Я пытаюсь понять, зачем эту мета информацию надо всегда передавать.
И прок от нее в чем, если мне надо глазками посмотреть адрес ссылки и понять, что связанные группы пользователя надо выбирать по url users/{id}/groups, если автоматом это не делается.
А я говорю об API на безе REST которым может пользоваться пару сонет не известных и не подконтрольных вам продуктов
это понятно, я просто с точки зрения клиента пытался понять полезность для меня таких ссылок.
Хорошо, но получается на стороне сервера, при создании пользователя надо отрабатывать так же ситуацию создания в том числе и группы?
Клиент при этом должен знать, что запрос можно сформулировать двумя способами (связать с существующей группой, связать с новой).
Получается, ссылки позволяют это описать легко в запросе, но реализация серверной части и клиентской становится труднее (лично я тут привык придерживаться принципа KISS)
Обе функции работают и часто встречаются, но давай-те подумаем, что получение идентификаторов скорее связано с необходимостью создать более сложный объект, который и будет ссылаться на эти самые идентификаторы.
В своей практике никогда не приходилось делать методов, которые отдают только идентификаторы, но вполне возможно мне просто повезло :)
Когда может возникнуть такая задача? Ну т.е. то, что клиент хочет создать новый объект с ссылками на другие объекты, про которые он пока ничего не знает? Мне может прийти на ум только создание нового объекта на основе существующего.
У меня сейчас основной вопрос в следующем. Схема с ссылками интересная — не только идентификатор передается, но и по сути как получить полное описание объекта.
Но по факту пока приходится писать обработку этих ссылок ручками.
Чего хотелось бы на стороне клиента (на js или .NET не суть), так это возможности описать, что:
— у нас есть классы order, orderitem, invoice
— у нас есть некие связи между ними
Далее, на стороне клиента, получили мы список всех order (ну или части), items мы пока в интерфейсе нигде не показывали (и сервер отдал только ссылки на них, а может и уже полностью), но как только мы из модели обратились к items, у нас по всем ref и прочим этим штукам, внутри сами по себе (через ajax для js) подгрузились эти данные.
Или к примеру, мы загрузили список order, потом в другом месте загрузили список invoice, а за счет того, что мы получили links в обоих ответах, на нашей стороне объекты заодно и связались (для invoice не надо будет заново загружать order, информация по нему у нас есть).
Именно в этом случае, возможно и правда есть смысл именно в таких ссылках. Пока такого нет, не уверен, что информацию о том, как вытащить объект надо описывать в ответе сервера, а не в модели на стороне клиента. Выглядит красиво, но на сколько реально это упрощает разработку?
Ок, где лежит объект с идентификатором 12345678? Как мне его получить?
Вряд ли вы сможете ответить на этот вопрос, а вот где лежит объект с идентификатором
foo.com/users/12345678
Как его получить?
Думаю, ответ на второй вопрос будет куда проще и понятнее.
Это понятно все, link несет дополнительную информацию о том, как получить этот объект (плюшки от этого ясны), я про другое. Когда может возникнуть необходимость отдавать именно link, заместо самого объекта? Когда это целесообразнее?
С заказом я имел ввиду вот что, пример с ссылками:
item полноценный объект, т.е. со всеми своими полями сразу.
Вопрос в том, что в случае получения конкретного order, скорее всего надо отдать и развернутые item, а не ссылки на них (иначе отображать вообще нечего будет). Иначе придется делать еще один запрос для получения всех items заказа (оно точно всегда так надо?)
А пример с order-collection так вообще страшный, т.к. по такому ответу можно узнать только общее кол-во объектов типа order и ссылки на них. А в списке хотелось бы хотя бы общую информацию, что бы как то отобразить можно было это.
В итоге основной вопрос — где грань между ссылкой и полноценным объектом? Какие плюсы со стороны клиента мы получаем при использовании ссылок?
Кстати, Viber под windowsphone в этом плане очень плох и не доработан — когда активировал desktop приложение, пуш уведомление с кодом активации пришло, а вот открыться не смогло, и те же стикеры отсутствуют, да и так по мелочи, звонки так вообще толком не работали у меня. Думаю, что приложение было сделано для галочки и пока объем пользователей не заставляет делать версию лучше.
Зато, в отличии от whatsapp у Viber есть desktop клиент.
Хотя по факту, REST просто выглядит как stateless протокол для клиента. В реализации он может быть не менее statefull чем и остальные. Вообще если сравнивать stateless протокол и statefull протокол — то надо смотреть не на реализацию, а на то, как он выглядит для клиента, ведь это stateless\full именно для клиента, а не для реализации.
На вопрос, а зачем же тогда основное приложение в AnyCPU, а не в x86, раз известна такая зависимость — она как раз неизвестна, приложение подгружает плагины, которые могут быть зависимы уже от либы, которая есть только в x86.
У меня была следующая проблема, была внешняя библиотека (написанная даже не под .NET) под x86. Она подключалась к исполняемому файлу, который был собран как AnyCPU. Все это хорошо работает на 32 разрядной системе, но при попытке запуска на 64-разрядной, приложение запускается (т.к. оно AnyCPU) в x64, и соответственно оно не может загрузить нужную библиотеку. Скорее всего я не очень долго искал (как AnyCPU приложение запустить в режиме x86 на 64-разрядной системе), но что то мне подсказывает, что это должно как то настраиваться?
в этом примере:
ссылка
описывает, что у пользователя есть группы, и их можно получить вот так то. Т.е. это некая мета информация об объекте.
Если я работаю с пользователем и знаю что он может быть в группах, мне эта информация не на столько важна (я скорее всего уже знаю как получить группы пользователя). Или возможно эта информация есть в описании документации. Я пытаюсь понять, зачем эту мета информацию надо всегда передавать.
И прок от нее в чем, если мне надо глазками посмотреть адрес ссылки и понять, что связанные группы пользователя надо выбирать по url users/{id}/groups, если автоматом это не делается.
это понятно, я просто с точки зрения клиента пытался понять полезность для меня таких ссылок.
Клиент при этом должен знать, что запрос можно сформулировать двумя способами (связать с существующей группой, связать с новой).
Получается, ссылки позволяют это описать легко в запросе, но реализация серверной части и клиентской становится труднее (лично я тут привык придерживаться принципа KISS)
В своей практике никогда не приходилось делать методов, которые отдают только идентификаторы, но вполне возможно мне просто повезло :)
Когда может возникнуть такая задача? Ну т.е. то, что клиент хочет создать новый объект с ссылками на другие объекты, про которые он пока ничего не знает? Мне может прийти на ум только создание нового объекта на основе существующего.
Но по факту пока приходится писать обработку этих ссылок ручками.
Чего хотелось бы на стороне клиента (на js или .NET не суть), так это возможности описать, что:
— у нас есть классы order, orderitem, invoice
— у нас есть некие связи между ними
Далее, на стороне клиента, получили мы список всех order (ну или части), items мы пока в интерфейсе нигде не показывали (и сервер отдал только ссылки на них, а может и уже полностью), но как только мы из модели обратились к items, у нас по всем ref и прочим этим штукам, внутри сами по себе (через ajax для js) подгрузились эти данные.
Или к примеру, мы загрузили список order, потом в другом месте загрузили список invoice, а за счет того, что мы получили links в обоих ответах, на нашей стороне объекты заодно и связались (для invoice не надо будет заново загружать order, информация по нему у нас есть).
Именно в этом случае, возможно и правда есть смысл именно в таких ссылках. Пока такого нет, не уверен, что информацию о том, как вытащить объект надо описывать в ответе сервера, а не в модели на стороне клиента. Выглядит красиво, но на сколько реально это упрощает разработку?
Это понятно все, link несет дополнительную информацию о том, как получить этот объект (плюшки от этого ясны), я про другое. Когда может возникнуть необходимость отдавать именно link, заместо самого объекта? Когда это целесообразнее?
С заказом я имел ввиду вот что, пример с ссылками:
Пример без ссылок (пусть ссылка сама на себя останется):
item полноценный объект, т.е. со всеми своими полями сразу.
Вопрос в том, что в случае получения конкретного order, скорее всего надо отдать и развернутые item, а не ссылки на них (иначе отображать вообще нечего будет). Иначе придется делать еще один запрос для получения всех items заказа (оно точно всегда так надо?)
А пример с order-collection так вообще страшный, т.к. по такому ответу можно узнать только общее кол-во объектов типа order и ссылки на них. А в списке хотелось бы хотя бы общую информацию, что бы как то отобразить можно было это.
В итоге основной вопрос — где грань между ссылкой и полноценным объектом? Какие плюсы со стороны клиента мы получаем при использовании ссылок?
авторизацию и аутентификацию в MVC никто не отменял, работает и для WebAPI.
это скорее задача веб-сервера, а не веб-сайта.