Как мне найти веб-сервисы RESTful?
Когда я хочу найти "Большой" веб-сервис (на основе WS-*/WSDL) требуемой функциональности, я могу просто зайти в поисках ".... filetype:wsdl", потому что Google индексирует также определения WSDL. Или я могу просто использовать некоторые реестры, которые уже просканировали для меня определения WSDL, например, SeekDa.com или ServiceFinder.
Когда я хочу найти RESTful Web-сервис (RESTful Web API), я могу рассчитывать только на сообщество, потому что невозможно различить URI RESTful Web-сервиса и другие веб-ресурсы (например, URL-адреса веб-сайтов), и, следовательно, любой целевой сканер не может скажи на 100% уверен: это URI Web-сервиса RESTful. Итак, я захожу, например, на ProgrammableWeb.com и надеюсь, что кто-то уже использовал / нашел нужную мне услугу и зарегистрировал ее там.
Недавно я искал веб-сервис для расширения аббревиатур. Я не смог найти его в таких порталах, как ProgrammableWeb, потому что никто не поместил его там. Наконец, я был вынужден просмотреть несколько сайтов словарей аббревиатур, покопаться и изучить их, и наконец нашел API веб-сервиса Abbreviations.com в форме RESTful. Это заняло у меня много времени!
Есть ли другой способ обнаружить веб-сервисы RESTful в Интернете?
4 ответа
Идеал REST заключается в том, что сервисы являются такими же потребляемыми, как и веб-страницы, им не нужны реестры. [Должен признать, что я не полностью "понимаю" последствия этого мира RESTful, без WSDL, без реестра, как будто езда на велосипеде без стабилизаторов.]
В старом Интернете, до Google, как мы нашли страницы? Эффективно из уст в уста и несколько ключевых отправных точек. Насколько я понимаю, REST-сервисы находятся на стадии, предшествующей Google.
Я не согласен с тем, что "невозможно отличить URI веб-службы RESTful от других веб-ресурсов" - если мы перейдем по ссылке, то получим определенные типы контента application/xml и application/json были бы довольно сильными индикаторами т они?
Существует соглашение (рекомендуется, например, в REST API Design Handbook), что конечную точку /api следует предоставлять в корне вашей службы. Это возвращает ответ XML или JSON, содержащий "дочерние" ресурсы, которые поддерживает ваша служба, например /api/products
Для веб-сервисов REST существует WSDL-подобный файл: он называется WADL.
SoapUI теперь может обнаружить службы REST. Он работает как прокси, записывая все запросы / ответы, которые проходят через. Наличие запросов и ответов SoapUI воссоздает описания / определения сервисов. Теперь определения могут храниться в форматах WADL и WSDL (как WSDL и XML-схема в мире XML). Это также может быть сохранено в формате Swagger. Я предпочитаю Swagger. Swagger может храниться в SwaggerHub прямо из SoapUI, который похож на GitHub для исходного кода. SwaggerHub - одна из многих систем управления API.