Скорее, у них в совокупности всё лучше — и движок, и сервис и, соответственно, маркетинг. Но деньги на маркетинг часто есть у тех, у кого хорошо налажены остальные процессы.
Это сейчас не нашёл в гугле — перестал искать. А тогда поисковые выдачи разных поисковиков очень сильно отличались, не найдя чего-то в Yandex — шли на Rambler, с рамблера — на апорт, с апорта — на Yahoo или ещё куда. И просматривали по 10-15 страниц выдачи. Поисковики не были такими совершенными как сейчас!
Спасибо за статью! У меня вопрос — а если бы стояла задача сделать так, чтобы при переходе из мобильной версии (нативного приложения а не сайта) в веб-версию не надо было логиниться дважды?
Мне кажется, компания Go была хорошей компанией как и любая компания, в которую вливают сразу много инвестиций. И естественно все остались довольны — выражаясь по-русски, бабло распилено, инвесторы высосаны, пора поискать новый стартап.
В ряде приложений (например, FOREXTrader), над которыми я работал, токен не продлевается — он просто имеет свой Time To Live (TTL), обычно равный от 2-3 минут до часа. А когда приходит ошибка «token expired», нужно повторить реквест авторизации с именем и паролем и повторить тот запрос, на котором пришёл expiration.
Так что не всегда клиенту нужно тупо вывести сообщение об ошибке, и тут как раз приходят коды.
По крайней мере, я не раз видел такую архитектуру в довольно серьёзных приложениях.
Согласен по поводу того, что сообщения об ошибка должны быть user-friendly и содержать посыл к действию. У меня такие вопросы:
— почему ошибок заведомо больше чем кодов?
— код нужен программисту, т.к. в абсолютном большинстве приложений локализация происходит на стороне клиента. Возможно, и лучше было бы перенести её на сервер, но знаю 90% реальных приложений, которые так устроены, и только 10% (действительно энтерпрайз), в которых это реализовано. А прикладному сервисному программисту особо не предлагают выбирать — очень часто заказчик приходит с уже готовыми веб-сервисами.
Что код не нужен пользователю — конечно, это самая бесполезная на свете информация. Видел пару раз (особенно в программах, разработанных в НИИ) как в сообщение об ошибке вставляют и код ошибки, и даже непонятное для пользователя имя класса, в котором произошла ошибка.
Это если бросить через WebView. У меня есть такое наблюдение — скорее всего, в WebView используется какая-то урезанная версия WebKit. Было много случаев, когда сайт открывался с Safari, но не открывался в WebView. К тому же пользователь иногда может хотеть уйти из WebView в браузер, например кликнет по ссылке (нехорошо его насильно удерживать в WebView).
Почему как и все? Например, человек в комментарии на один выше вашего согласен. В протоколе HTTP как раз и придумали 5XX ошибки для того, чтобы сказать: реквест выполнился, но произошла ошибка. Другое дело, что годами сложилась практика, где это не используют, а код ошибки передают в самом сообщении.
Ну ведь и про HTTP-шные PUT и DELETE на много лет забыли, а потом пришёл REST и всё расставил по местам. Т.е. он стал использовать протокол HTTP не просто как транспортный уровень для XML/JSON, но стал использовать все его возможности, которые изначально закладывались умными людьми.
По поводу errorText — если клиент его не будет использовать, в продакшне это будет просто лишний текст, который гоняется туда-сюда. В 2012 году мы не привыкли экономить байты, но у меня после программирования на слабых контроллерах рука не поворачивается делать такую избыточность :)
Тогда, конечно, другое дело — я писал только об HTTP. Дополнительный уровень абстракции накладывает дополнительные ограничения.
Вообще — да, не привыкли мы использовать HTTP коды, для меня это тоже было дико когда впервые услышал такое предложение. Но потом понял, что это удобно :)
С куками (они же индетификаторы сессии в большинстве случаев) тоже никаких проблем нет
Хотя я против сессий в апи.
Так вы против или нет проблем?
Ну если уж вы переходите в вебвью, то это проблемы проектирования.
Напротив, если бы вы внимательно читали пост — поняли бы, что я против такого подхода.
Зачем вообще нужно приложение, которое урезано и половина функционала в вебвью?
Разные случаи бывают. Бывает, что нужно совершить покупку внутри приложения (не IAP, а как на ебэе например) — делать внутри Эпл запрещает. Бывает, бюджет и сроки. Не судите столь категорично.
Да и вообще, ваш стиль комментария отталкивает от того, чтобы его комментировать.
Передавать язык клиента можно, но тоже не слишком удобно.
1) В этом случае локализация не будет инкапсулирована в одном месте, т.к. локальные сообщения и просто стринги всё равно нужно будет хранить на стороне приложения. Это не критично, просто не очень удобно.
2) Придётся в каждом запросе отправлять код локали и анализировать на стороне сервера. Больше кода.
В моём подходе одна проблема — все ошибки нужно учесть ДО загрузки приложения в аппстор. Но как показывает практика, новые кейсы (и, соответственно, новые ошибки) происходят после добавления функционала в приложение, т… е приложение всё равно придётся перезаливать в аппстор.
Нет, почему, можно возвращать например статус 520, а в проектной документации договориться, что это значит 'Some valuable parameter is not provided'. Клиент будет знать, что за ошибка, и правильно её обработает. Т.е. на все ошибки будут просто разные статусы HTTP. Это, конечно, работает если заведомо известно что их не будет больше 80-ти. Если же их будет больше, можно просто возвращать код ошибки в JSON как вы написали — без самого текста сообщения, который клиент сможет вывести сам, красивый и локализованный.
— «Молодой человек, вы что, не видите — вся на витрине!!»
— «Какая котлета посвежее?»
— «Берыце, усё укусна...»
(Мои домыслы, могу и ошибаться)
Так что не всегда клиенту нужно тупо вывести сообщение об ошибке, и тут как раз приходят коды.
По крайней мере, я не раз видел такую архитектуру в довольно серьёзных приложениях.
— почему ошибок заведомо больше чем кодов?
— код нужен программисту, т.к. в абсолютном большинстве приложений локализация происходит на стороне клиента. Возможно, и лучше было бы перенести её на сервер, но знаю 90% реальных приложений, которые так устроены, и только 10% (действительно энтерпрайз), в которых это реализовано. А прикладному сервисному программисту особо не предлагают выбирать — очень часто заказчик приходит с уже готовыми веб-сервисами.
Что код не нужен пользователю — конечно, это самая бесполезная на свете информация. Видел пару раз (особенно в программах, разработанных в НИИ) как в сообщение об ошибке вставляют и код ошибки, и даже непонятное для пользователя имя класса, в котором произошла ошибка.
Ну ведь и про HTTP-шные PUT и DELETE на много лет забыли, а потом пришёл REST и всё расставил по местам. Т.е. он стал использовать протокол HTTP не просто как транспортный уровень для XML/JSON, но стал использовать все его возможности, которые изначально закладывались умными людьми.
По поводу errorText — если клиент его не будет использовать, в продакшне это будет просто лишний текст, который гоняется туда-сюда. В 2012 году мы не привыкли экономить байты, но у меня после программирования на слабых контроллерах рука не поворачивается делать такую избыточность :)
Со всем остальным согласен.
Вообще — да, не привыкли мы использовать HTTP коды, для меня это тоже было дико когда впервые услышал такое предложение. Но потом понял, что это удобно :)
Так вы против или нет проблем?
Напротив, если бы вы внимательно читали пост — поняли бы, что я против такого подхода.
Разные случаи бывают. Бывает, что нужно совершить покупку внутри приложения (не IAP, а как на ебэе например) — делать внутри Эпл запрещает. Бывает, бюджет и сроки. Не судите столь категорично.
Да и вообще, ваш стиль комментария отталкивает от того, чтобы его комментировать.
1) В этом случае локализация не будет инкапсулирована в одном месте, т.к. локальные сообщения и просто стринги всё равно нужно будет хранить на стороне приложения. Это не критично, просто не очень удобно.
2) Придётся в каждом запросе отправлять код локали и анализировать на стороне сервера. Больше кода.
В моём подходе одна проблема — все ошибки нужно учесть ДО загрузки приложения в аппстор. Но как показывает практика, новые кейсы (и, соответственно, новые ошибки) происходят после добавления функционала в приложение, т… е приложение всё равно придётся перезаливать в аппстор.