Я новичок в RAML, и у меня есть основной вопрос:Несколько baseUri в RAML?
Невозможно указать набор альтернативных baseUri (разрешен только один). Есть ли альтернативный способ моделирования нескольких альтернативных установок API (например, для отдельных сред цикла релиза)?
Способ, которым я общаюсь с этим шаблоном baseUri.
Для виртуальной машины Java приложений я использую:
baseUri: ${baseUri}
и сделать файл Raml как JSP.
Для Ruby-приложений я использую:
baseUri: <%= base_uri >
и делают, как Еврорадио.
Значение для baseUri рассчитывается «на лету» на основе входящего запроса, поэтому оно всегда соответствует хосту/домену, где он развернут.
Одним из способов может быть использование baseUriParameters и использование значения перечисления для различных развертываний.
#%RAML 0.8
title: Some Service
version: 1
baseUri: https://{environment}/rest/v{version}/services/someservice
baseUriParameters:
environment:
description: Integration test, Acceptance Integration Test, Production
enum: ["test-api.company.com","acc-api.company.com","api.company.com"]
Ницца! Я предполагаю, что решение, которое я предоставил, было бы правильным для компоновки этого свойства вручную (т. Е. Типа контракта), в то время как указанный вами метод формирует это свойство на основе фактической реализации (то есть стиля развертывания). – nize
Ну, я сторонник контракта - во-первых, и я думаю, что RAML действительно поддерживает и поощряет подход, основанный на контракте, очень хорошо. Но фиксация значения «baseUri» в предопределенном наборе была бы слишком невыполнимой, особенно когда вы выполняете переходные облачные развертывания интегрированных сборок, окончательный URI которых является случайным (генерируется поставщиком облачных вычислений). –