Pull to refresh

Comments 21

Хоть и земляки, но не удержусь — за такое Api надо отрезать кое-что. У вас вроде даже IoC контейнер свой есть, а вот нормальный REST Api не осилили. Точнее у вас обычный RPC. Как у вас отличаются операции создания, изменения и частичного изменения?
Вообще-то, если посмотреть документацию diadoc.kontur.ru/sdk/, то можно убедиться, что применяются принципы REST. А то, что некоторые операции делаются в одной не считаю критичной проблемой.
en.wikipedia.org/wiki/HATEOAS

Из Википедии:

Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC). Подход RPC позволяет использовать небольшое количество сетевых ресурсов с большим количеством методов и сложным протоколом. При подходе REST количество методов и сложность протокола строго ограничены, из-за чего количество отдельных ресурсов может быть большим.

В случае Диадока у нас как раз большое количество сетевых ресурсов, т.е. согласно REST.
ParseAcceptanceCertificateSellerTitleXml — не ресурс (документ), а операция.
Он был бы REST, если бы:
1. У вас был ресурс AcceptanceCertificateSellerTitle. (Без Xml!). Допустим коллекция этих ресурсов по URL: www.diadoc.ru/api/v1/AcceptanceCertificateSellerTitles
2. У этого ресурса можно было бы сделать POST для создания нового тайтла и в ответ получить Created и ссылку где он находится вида: www.diadoc.ru/api/v1/AcceptanceCertificateSellerTitles/{mytitle}

То, что вам приехал XML вы должны были взять например из ContentType.
Где это написано в спецификации REST?
Вы специально пропускаете ссылку про HATEOAS. У вас операция, не ресурс. В чем разница между /GetUserName и /users/vasyapupkin/name?

PS Спасибо за минуса.
Я минусы не ставил, видимо, кто-то другой постарался. На самом деле, формат URL у ресурсов может быть разным и не обязательно таким, как вам хочется.
Как раз формат очень важен. Именно за счет формата можно всегда однозначно написать /users/vasyapupkin/groups если ресурс user может содержать ресурсы типа groups.

С вероятностью процентов 90% у вас используются ASP.NET MVC контроллеры для этой задачи. Они не очень хорошо предназначены для этого и на них проще как раз делать обычный RPC(такой подход например используется в TFS 2012).
Если вы возьмете WebApi, то по дефолту там у контроллеру увидите не Parse, Update и тд, а GET, POST, PUT, DELETE. Это типы действий которые вы можете произвести над ресурсом. Причем PUT например должен быть идемпотентным.

В видео, которое я приводил выше, очень хорошо рассказано про то, как создать грамотный REST Api.
Вот ссылка на их описание Api: www.stormpath.com/docs/rest/api
Все-таки нужно понимать разницу между «Tipicaly used» и «Mandatory»
И насчет HATEOAS тоже у программиста может быть выбор — использовать это или нет. Да, Диадок не похож на Твиттер, но это не значит, что нужно их ругать.
Тогда это обычный XML RPC over HTTP. И называть его REST не корректно.
Как-то вроде и всё рассказали, но в то же время слишком кратко и сухо. Например хотелось бы больше про использование кассандры. Мы вот тоже используем кассандру в продакшене. Хочется послушать про возникшие проблемы и способы их решения.
Наверное, это тем для отдельной статьи
Честно говоря ожидал больше подробностей, чем просто список используемых на проекте технологий. Все-таки под словом «архитектура» подразумевается нечто большее.
Спасибо что поделились.

Любой рассказ о высокой нагрузке должен сопровождаться тем, какую нагрузку УЖЕ выдерживает система на тестах ли или живых пользователях. На что вы рассчитываете в теории совершенно не важно. Потому что под реальной нагрузкой, так или иначе ложились, пожалуй, все крупные проекты, хотя они тоже что-то там оценивали и планировали.

Картина dataflow из вышего описания выглядит несколько лоскутной.

И у меня небольшой вопрос, какие у вас максимальные размеры документа? Как внутри системы гоните блобы, через буферы или отдельно?
Sign up to leave a comment.