Есть ли способ обнаружить все конечные точки API-интерфейса ReST?

Мне интересно, возможно ли его программно обнаружить все конечные точки конкретного API.

Так, например, если я получаю этот URL с браузером или завитком: https://api.twitter.com/1.1/

Я мог бы получить что-то вроде этого как ответ JSON:

{"TwitterAPI":{
    "version" : 1.1,
    "GET" : {
        "search/" : ["users", "trending"],
        "users/" : ["id", "handle"]
    }
}

Конечно, Twitter мог бы опубликовать или не опубликовать этот формат. Итак, как вопрос, есть ли какие-либо библиотеки для Java или Javascript, которые будут автоматически отображать и публиковать маршруты API, созданные вами в ваших контроллерах?

Ответы

Ответ 1

Нет никакого способа программного обнаружения служб REST, поскольку они не имеют стандартной службы регистрации.

Помимо того, что вы делаете что-то безумное поиски грубой силы, нет способа найти правильные URL-адреса (не говоря уже о правильных параметрах). Таким образом, единственным вариантом является документирование вашего API. Для этого лучший выбор, который я видел до сих пор:

Ответ 2

Некоторые API RESTful публикуют ресурс языка описания веб-приложений (WADL - произносится как прогулка, которую делают утки - для краткости). JAX-RS или, по крайней мере, Jersy webapps будут делать это по умолчанию на корневом URL-адресе приложения /application.wadl. Не похоже, что Twitter API является одним из них. Многие пуристы REST утверждают, что API должен быть самоописательным и самоочевидным, просто взаимодействуя с ним и видя, какие другие конечные точки он вам даст.

Подробнее о WADL из википедии...

Ответ 3

Вы должны быть в состоянии обнаружить все, что вам нужно знать о REST API, только зная начальную точку входа. Это один из фундаментальных пунктов ОТДЫХА; что это должно быть обусловлено гипермедиа и самоописанием. Это также один из наименее понятых принципов. Обнаружение ресурсов сводится к гипермедиа-ссылкам в ответах от сервера.

Еще в 2008 году Роя Филдинга стали раздражать люди, которые пишут API на основе HTTP и называют их REST только потому, что это была горячая новость. Вот пара замечаний, которые он делает;

API REST не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу управления своим собственным пространством имен. Вместо этого позвольте серверам инструктировать клиентов о том, как создавать соответствующие URI, например, в HTML-формах и шаблонах URI, определяя эти инструкции в типах мультимедиа и ссылочных отношениях. [Ошибка здесь подразумевает, что клиенты принимают структуру ресурса из-за внеполосной информации, такой как специфичный для области стандарт, который является ориентированным на данные эквивалентом функциональной связи RPC].

а также

API REST следует вводить без каких-либо предварительных знаний, кроме начального URI (закладки) и набора стандартизированных типов мультимедиа, подходящих для целевой аудитории (то есть ожидается, что их поймет любой клиент, который может использовать API). С этого момента все переходы состояний приложения должны определяться выбором клиентом предоставленных сервером вариантов, которые присутствуют в полученных представлениях или подразумеваются пользовательскими манипуляциями с этими представлениями. Переходы могут быть определены (или ограничены) знаниями клиентов о типах мультимедиа и механизмах связи с ресурсами, которые могут быть улучшены на лету (например, код по запросу). [Ошибка здесь подразумевает, что внешняя информация движет взаимодействие вместо гипертекста.]

На практике это означает, что точка входа (обычно с использованием корневого URI "/") содержит ссылки на другие API REST. Эти API будут содержать ссылки на другие API и так далее. Не должно быть API, который не имеет ссылки на него. Это означало бы, что это не обнаружено.

Другие ответы здесь в корне неверны в том, что они не признают самый основной принцип REST.