Правильней было бы так сформулиривать - требование следовать ему всегда/везде - это плохо. имхо, есть только один паттерн - здравый смысл. но это слишком абстрактно и плохо формализуется. А restful, solid, clean code и иже с ними - нужно применять только там, где нужно (сорри за тавтологию)
Хорошая статья. Но хотелось бы рассмотреть тему с другой стороны. HTTP коды не тоже самое что бизнес-коды. HTTP методы не равны бизнес-методам. Поэтому REST хорошо, а RESTful (в обычном пониманиии: GET -Получение, POST- Создание, PUT/PATCH - Обновление, DELETE - Удаление) это плохо. Идемпотентность - это бизнес правило. Сейчас get /users/123 вернет одно, а через 5 минут другое. Или счетчик какой-то увеличится. Конечно, неперехваченная ошибка - это 500, не авторизированный запрос - это 401, нет прав - 403, нет страницы - 404. Остальное - обсуждается (или ставится не вами, например,таймаут). Обычно это 400 Bad Request. PS. и на вентилятор, проходилось посылать/принимать даные в body для get, и в query-string для post. А еще и в header'е.
Наверное, Perforce. Уже давно работаю только с Git-ом, поэтому текущее состояние не знаю :( Но server-based системы, в отличие от распределенных, поддерживают очень большие репозитории, что бывает важно, если разные модули д.б. констистентны, т.е. лежать в одном репозитории. И, конечно, если вам не нужны все сорсы, то, что брать и куда скачивавать, настраивается при помощи workspace.
Как пользователь, работавший с различными SCM-и (SourceSafe, SVN, Perforce, PlasticSCM и Git), я считаю, что low-level потроха, торчащие из GIT-a, мешают программисту, если, конечно, он не разработчик SCM-а :) IMHO, Git - это не для энтерпрайза, но "модно-молодёжно", и поэтому, к сожалению, везде :(
если формировать HTTP request ручками (т.е. на низком уровне) - то есть и query string, и body, и header. А HTTP verb можно любой подставить.
Правильней было бы так сформулиривать - требование следовать ему всегда/везде - это плохо.
имхо, есть только один паттерн - здравый смысл. но это слишком абстрактно и плохо формализуется. А restful, solid, clean code и иже с ними - нужно применять только там, где нужно (сорри за тавтологию)
Хорошая статья. Но хотелось бы рассмотреть тему с другой стороны.
HTTP коды не тоже самое что бизнес-коды.
HTTP методы не равны бизнес-методам.
Поэтому REST хорошо, а RESTful (в обычном пониманиии: GET -Получение, POST- Создание, PUT/PATCH - Обновление, DELETE - Удаление) это плохо.
Идемпотентность - это бизнес правило. Сейчас get /users/123 вернет одно, а через 5 минут другое. Или счетчик какой-то увеличится.
Конечно, неперехваченная ошибка - это 500, не авторизированный запрос - это 401, нет прав - 403, нет страницы - 404.
Остальное - обсуждается (или ставится не вами, например,таймаут). Обычно это 400 Bad Request.
PS. и на вентилятор, проходилось посылать/принимать даные в body для get, и в query-string для post. А еще и в header'е.
А будет версия для Visual Studio?
Наверное, Perforce.
Уже давно работаю только с Git-ом, поэтому текущее состояние не знаю :(
Но server-based системы, в отличие от распределенных, поддерживают очень большие репозитории, что бывает важно, если разные модули д.б. констистентны, т.е. лежать в одном репозитории. И, конечно, если вам не нужны все сорсы, то, что брать и куда скачивавать, настраивается при помощи workspace.
Как пользователь, работавший с различными SCM-и (SourceSafe, SVN, Perforce, PlasticSCM и Git), я считаю, что low-level потроха, торчащие из GIT-a, мешают программисту, если, конечно, он не разработчик SCM-а :)
IMHO, Git - это не для энтерпрайза, но "модно-молодёжно", и поэтому, к сожалению, везде :(
а зачем?