Примеры лучших веб-API SOAP/REST/RPC? И почему Вам нравятся они? И что случилось с ними? [закрытый]
Может быть немного не по теме, но это то, что у нас есть для List<T>, а не Stream<T>.
Сначала вам понадобится метод take util. Эти методы принимают первые n элементы:
static <T> List<T> take(List<T> l, int n) {
if (n <= 0) {
return newArrayList();
} else {
int takeTo = Math.min(Math.max(n, 0), l.size());
return l.subList(0, takeTo);
}
}
он работает только как scala.List.take
assertEquals(newArrayList(1, 2, 3), take(newArrayList(1, 2, 3, 4, 5), 3));
assertEquals(newArrayList(1, 2, 3), take(newArrayList(1, 2, 3), 5));
assertEquals(newArrayList(), take(newArrayList(1, 2, 3), -1));
assertEquals(newArrayList(), take(newArrayList(1, 2, 3), 0));
, теперь будет довольно просто написать метод takeWhile на основе на take
static <T> List<T> takeWhile(List<T> l, Predicate<T> p) {
return l.stream().
filter(p.negate()).findFirst(). // find first element when p is false
map(l::indexOf). // find the index of that element
map(i -> take(l, i)). // take up to the index
orElse(l); // return full list if p is true for all elements
}
он работает следующим образом:
assertEquals(newArrayList(1, 2, 3), takeWhile(newArrayList(1, 2, 3, 4, 3, 2, 1), i -> i < 4));
эта реализация повторяет список частично в течение нескольких раз, но не добавляет add O(n^2) операций , Надеюсь, это приемлемо.
7 ответов
Вот мое взятие.
-
, Хотя происходя из точки зрения Java, я на самом деле предпочитаю REST. Конверт SOAP с несколькими пространствами имен и его сложной структурой является отвращением. Это пытается решить главным образом мнимые проблемы, и ничего не решает эффективно. Только вещь о SOAP, который я нашел полезными, состоит в том, что он имеет стандарты для авторизации и ошибок. С другой стороны, оба могли быть решены намного легче включением четырех стандартных атрибутов в корневом элементе XML - имя пользователя, пароль, errorCode, errorDescription.
-
Хорошее описание API и документация - действительно все, что имеет значение. Различие между REST и SOAP в зрелой платформе находится главным образом в нескольких строках конфигурации.
-
Для SOAP, отправьте хеш как часть безопасности SOAP; для REST мне нравится упаковывать все в полезной нагрузке и избегать HTTP-заголовков для аутентификации. У меня есть только субъективные причины, хотя, так как я должен был бороться с платформами, которые легко не представляют HTTP-заголовков.
-
Мое персональное предпочтение имеет различный URIs для различных версий протокола. По моему опыту, это дает Вам больше гибкости в более новых версиях, и старые клиенты, которые соединяются с неподдерживаемыми версиями протокола, прекращают работать сразу и по очевидным причинам. Кроме того, иногда можно отобразить старую версию приложения к старому URI, чтобы не иметь код поддержки прежней версии в новой серверной версии.
Что касается того, сколько времени Вы поддерживаете старую версию протокола... идеально, пока у Вас есть клиенты, которые используют его. Это - больше бизнеса, чем техническое решение. Необходимо поддерживать по крайней мере одну предыдущую версию протокола. Это обычно находится в Вашем интересе продвинуть клиенты к новой версии понижать затраты на поддержку прежней версии; с клиентской стороны новая версия должна означать новые возможности, лучший протокол и своего рода дополнительный бизнес-стимул (если одни только новые возможности недостаточно).
Вы могли бы интересоваться представлением Joshua Bloch, "Как Разработать Хороший API и Почему оно Вопросы". Joshua Bloch является автором "Эффективного Java" и Основным Разработчиком программного обеспечения и Главным Архитектором Java в Google.
Краткий обзор: http://portal.acm.org/citation.cfm?id=1176622
Управление версиями для REST с помощью заголовков Типа контента покрыто хорошо здесь: http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
REST, если сделано правильно, легко понять (модели HTTP), простые (ориентированный ресурс), и может быть проанализирован в значительной степени каждым языком программирования (XML).
Я видел бы то, что Amazon делает - http://aws.amazon.com/ - парни, делающие деньги от этого материала, очевидно, узнают больше уроки, чем кто-либо еще.
Другой API я посмотрел бы на - API salesforce.com и Microsofts CRM был довольно интересен. Twitter имеет укрепленный API REST сражения также.
Если Вы не можете решиться в конечном счете, что Вы могли бы реализовать их всех. В этих случаях полезно посмотреть, как другие сделали его. Я рекомендую Вам Собственная База данных XML, С открытым исходным кодом существует , что предложения три типа интерфейсов Вы - intestigating.
По моему скромному мнению, все это зависит от того, какие приложения Вы предлагаете. Если Вы делаете важные транзакции достижения, то определенно идут с SOAP (WS "звезда смерти", как они называют его). Но если Вы предлагаете социальные приложения, затем пойдите с REST, так как это более просто и лучшее пригодное для общедоступного взламывания.