Выбор метода для веб-сервиса - PullRequest
2 голосов
/ 18 июня 2010

Меня просят настроить новый веб-сервис, который должен легко использоваться на любом языке (php, .NET, Java и т. Д.). Конечно, можно свернуть мой собственный, принимая разные типы контента (xml / x-www-form-urlencoded (нормальный пост) / json / и т. Д.), Но существующий метод или механизм, конечно, предпочтительнее, сокращая время потрачено на разработку для потребителей услуги.

Веб-сервис действительно принимает модификации / наборы (это не только простой поиск данных), но они, скорее всего, будут намного меньше, чем получает (мы оцениваем около 2,5% наборов, 97,5 получает). Термин веб-сервис здесь означает, что протокол должен проходить через HTTP, не имея возможности реализовать его полностью на стороне клиента (javascript в браузере конечных пользователей и т. Д.), Так как он требует специальной аутентификации пользователя.

Обе функции получают и устанавливают довольно легко на счетчик параметров (обычно от 1 до 4). Такие методы, как REST (который я бы предпочел только для получения), XML-RPC и SOAP (может быть немного излишним, но имеет преимущество явно определенных методов и возвратов) - это обычные подозрения.

Какой, по вашему мнению / опыту, наиболее распространенный и наиболее легко реализуемый протокол на разных языках (с точки зрения потребителей), который может удовлетворить эту потребность?

Ответы [ 3 ]

3 голосов
/ 18 июня 2010

SOAP - это кошмар практически для любого потребителя, кроме Java и / или .NET, и, если что-то не изменилось, заставить клиента Java общаться с сервером .NET (или наоборот) очень трудно. Если вы идете по пути SOAP, вы в значительной степени отдаете себя и пользователей вашего веб-сервиса обязательству по поддержке инструментов, потому что никто не хочет иметь дело с SOAP вручную.

Вы можете написать потребителя для веб-службы RESTful практически на любом языке, потому что все, что ему нужно, это библиотека HTTP, хотя есть библиотеки для большинства основных языков, помогающие в таких вещах, как согласование типа содержимого и т. Д. Эти библиотеки кстати, большой выигрыш для сервера тоже.

A действительно API-интерфейс RESTful доступен для обнаружения по определению: гипертекст как двигатель состояния приложения (HATEOAS) является одной из определяющих характеристик REST. Чтобы быть справедливым, это обычно игнорируется в реальном мире, в основном потому, что это излишне. Что-то вроде AtomPub или одного из API-интерфейсов управления облачным сервером от Sun, вероятно, является хорошим примером действительно RESTful-сервиса.

Независимо от того, какой подход вы используете, вы должны самостоятельно составлять четкую документацию, а не полагаться на автоматически созданные документы. Это полезные ссылки, когда это необходимо, но они не заменяют собой хорошую рукописную документацию.

3 голосов
/ 18 июня 2010

Мы провели много исследований по этому вопросу и в итоге выбрали REST. Многие хорошо продуманные веб-сервисы используют REST, включая Amazon S3. Я думаю, что Gmail также использует REST на сервере.

По моим наблюдениям, дизайн веб-службы RESTful становится все более заметным, поскольку преимущества его дизайна и недостатки других проектов, таких как SOAP, становятся более очевидными с течением времени и опыта.

Причина, по которой REST, кажется, работает хорошо, заключается в том, что он естественным образом подходит для клиент-серверной природы Интернета с разделением безопасных и идемпотентных GET-запросов, идемпотентных PUT-запросов и POST для запросов, которые не являются ни безопасными, ни идемпотентная. Он существует уже давно, поэтому правильно разработанная веб-служба RESTful может использоваться различными веб-клиентами, некоторые из которых могут даже не ожидаться. Примером этого является то, что веб-сканер будет знать только о том, что он запрашивает ресурсы с помощью GET, поскольку гарантированно не влияет на ресурс, тогда как запросы PUT и POST имеют разные правила.

После того, как мы определились с архитектурой сервиса RESTful, я прочитал эту книгу: Веб-сервисы RESTful , чтобы изучить основы. Если вы решите его прочитать, знайте, что книга, возможно, вдвое длиннее, чем нужно, поэтому вам нужно быть осторожным с тем, что читать и что пропустить - потому что вы захотите пропустить пух.

0 голосов
/ 18 июня 2010

Сервис SOAP обладает тем преимуществом, что его можно обнаружить. В .NET (и, как я полагаю, на других языках) вы просто создаете новый класс веб-служб (.ASMX в ASP.NET) и добавляете любые методы в интерфейс, который вам требуется. Фреймворк сгенерирует для вас WSDL, который можно получить через HTTP. Этот WSDL содержит определение класса, которое используется вызывающим приложением, и предоставляет правильные имена и типы параметров для каждого метода. и т.д.

REST или другая обычно не обнаруживаемая служба имеет недостаток, заключающийся в том, что вам придется вести документацию для этого интерфейса вручную. Может быть сложнее отлаживать проблемы связи с клиентами без информации внутри и применения WSDL.

...