Не уверен, что использовать vim для разработки на C# хорошая идея, есть специализированные инструменты, типа студии (которая бесплатная в community edition), в которой таких проблем нет.
(а) реализации SOAP на этой и той стороне отличаются (например, вы по-разному трактуете время без указания часового пояса)
(б) в WSDL (точнее, XSD) описаны далеко не все детали формата, а в паре мест стоит xs:any.
Если API кривой, то не важно REST он, не REST, проблемы всё равно будут.
(ц) авторизация… авторизация? авторизация, мать ее!
не понял вас тут
А что такого в «стоимости разработки REST»? Чем она радикально выше, чем разработка под SOAP?
Ну, как минимум, надо свой транспорт писать. Формирование JSON, запрос к удалённому компьютеру, считывание ошибок, протоколирование, парсинг JSON обратно в объекты. В реализации SOAP майкрософта это всё идёт из коробки, вызвал функцию на сгенерированном прокси-классе, обратно получил результат, случилась ошибка — вывалился exception. Это работает прозрачно, как будто всё происходит в рамках одного процесса.
(а) простота использования из браузерного кода
(б) опора на существующую HTTP-инфраструктуру (например, кэширование)
(ц) «встроенная» мультиформатность
(д) более очевидная семантика
Тут согласен, но это делает его в основном пригодным только для фронтэнда. Причём в рамках одного домена, из-за ограничения на кроссдоменные запросы.
Как по мне, самый большой недостаток REST — высокие затраты времени на разработку. Если API предоставляется через SOAP (так поступает большинство крупных компаний банковского, страхового и других B2B секторов), достаточно взять кодогенератор, который из WSDL файла сгенерирует прокси классы и всё, через 3 минуты ты можешь делать запросы, при этом особенности транспорта тебя не волнуют. Круче всего это реализовал Microsoft в своём WCF, где через конфигурационный файл можно выбрать любой транспорт, от http(s) до MSMQ (включая tcp и named pipes). WSDL файл и SOAP автоматически генерируются на основе кода.
А REST, вот я так в толк и не возьму, какие у него основные плюсы. Меньше данных передаётся? В мире единицы сайтов, для которых экономия на траффике в таких масштабах превысит стоимость разработки REST.
Всё структурно? Да хз, как бы да, но реально дебажить приходится смотря на все 7 мест, указанных в статье. И опять же, если следовать RESTful, то те моменты, которые через RPC решаются за один запрос, через RESTful за кучу. Не понимаю я его смысл как «эталона», короче.
Очень хочется иметь возможность брать вкладку и утаскивать её на второй монитор как отдельное окно браузера. В старом интерфейсе это можно было делать. А сейчас приходится извращаться с копированием/вставкой адреса.
Предполагаю, её использование оправдано в ситуациях, когда надо часто удалять элементы из середины списка. Поскольку в ArrayList при этом происходит сдвиг элементов, каждое такое удаление будет сопровождаться выделением памяти под новый массив и копирование в него оставшихся элементов из старого. В LinkedList просто меняются указатели у соседей удаляемого элемента.
Не уверен на 100% на счёт Java, но предполагаю, что при увеличении массива, будет просто выделен новый кусок памяти, большего размера, куда будут скопированы значения из старого размера. При этом старый кусок памяти придётся удалять, т.е. дополнительно вырастет нагрузка на сборщик мусора.
Может слегка не в тему, но мы в своё время решили подобную задачу переведя котёл на евробрикеты. Горят так же, как и уголь, а золы ощутимо меньше. По стоимости получается примерно то же самое.
Мы сделали непредвзятое сравнение упомянутых систем по множеству параметров и разместили результаты в сводной таблице, попутно сделав небольшой обзор каждой системы в отдельности.
Непредвзятый обзор Cackle в блоге компании Cackle. Подозрительно напоминает оксюморон.
Мне кажется мы с вами о разных вещах говорим. С точки зрения текущей работы компиляторов — вы правы. С точки зрения прикладного программиста, который не заморачивается прогнозированием будущего (которое не спрогнозировать), для кода вида:
public static T Of<T>(this object o)
{
return (T) o;
}
Значение перечисления в атрибуте говорит о том, что нужно инлайнить, если возможно. А то что компилятор пока не умеет — не зона ответственности прикладного программиста.
Потому что сейчас не умеет, потом научится (по ссылке об этом говорится: «JIT today can't inline methods that contains „starg“ opcode»). Или другой компилятор будет уметь. А код с атрибутом останется.
Со 150 до 70 — это вообще не предел. Мой личный рекорд — со 180 до 33 юаней на Гуланью в Сямене. При этом девочка-продавец выглядела жутко довольной, а у меня сложилось впечатление, что можно было до 20-25 юаней опускать. Они в этом смысле совершенно беспринципные, когда видят европейца.
Не увидел противоречия, что ASMX работает через SOAP, что WCF работает через SOAP.
P.S. Чтобы не было холивара, последние 6 лет я только через WCF работаю ;)
Если API кривой, то не важно REST он, не REST, проблемы всё равно будут.
не понял вас тут
Ну, как минимум, надо свой транспорт писать. Формирование JSON, запрос к удалённому компьютеру, считывание ошибок, протоколирование, парсинг JSON обратно в объекты. В реализации SOAP майкрософта это всё идёт из коробки, вызвал функцию на сгенерированном прокси-классе, обратно получил результат, случилась ошибка — вывалился exception. Это работает прозрачно, как будто всё происходит в рамках одного процесса.
Конкретный пример — работа с транзакциями, описание разницы есть тут: habrahabr.ru/post/131343
Тут согласен, но это делает его в основном пригодным только для фронтэнда. Причём в рамках одного домена, из-за ограничения на кроссдоменные запросы.
А REST, вот я так в толк и не возьму, какие у него основные плюсы. Меньше данных передаётся? В мире единицы сайтов, для которых экономия на траффике в таких масштабах превысит стоимость разработки REST.
Всё структурно? Да хз, как бы да, но реально дебажить приходится смотря на все 7 мест, указанных в статье. И опять же, если следовать RESTful, то те моменты, которые через RPC решаются за один запрос, через RESTful за кучу. Не понимаю я его смысл как «эталона», короче.
P.S. Сам левша
Непредвзятый обзор Cackle в блоге компании Cackle. Подозрительно напоминает оксюморон.
Не очень понятно, что вы имели в виду.
запросить у компилятора встраивание разумно.
Потому что сейчас не умеет, потом научится (по ссылке об этом говорится: «JIT today can't inline methods that contains „starg“ opcode»). Или другой компилятор будет уметь. А код с атрибутом останется.
P.S. Чтобы не было холивара, последние 6 лет я только через WCF работаю ;)