Функция Spring Cloud подходит для REST API? Как получить доступ к параметрам пути GET?
Я новичок в WebFlux и Serverless. Я пытаюсь создать REST API как бессерверный через шлюз AWS API.
Поток будет: API Gateway -> Lambda -> DynamoDB.
Будет ли Spring Cloud Function лучшим выбором для достижения потока API? Я обнаружил, что aws-serverless-java-контейнер выполняет свою работу без проблем (оболочка преобразования события в HTTP-запрос / ответ)
Я просмотрел документацию по http://cloud.spring.io/spring-cloud-function/single/spring-cloud-function.html и несколько примеров, найденных в https://github.com/spring-cloud/spring-cloud-function. Но все же я не уверен, смогу ли я с помощью Spring Cloud Function добиться вкуса API.
@Bean
//How path or query params can be mapped?
public Function<Flux<String>, Flux<String>> getEmployeeDetails() {
// business logic goes here
}
В приведенном выше фрагменте показано, как реализовать модель запроса / ответа GET. Если моя конечная точка имеет / {dept} / {employee} / {name}, как облачная функция Spring принимает параметры пути в запросе GET?
Любые указатели были бы полезны.
Ответы 2
У меня та же ошибка с этим, документация подсказывает вам, что вы можете это сделать, но вы не можете. Это только пример из spring-cloud-function, а в конкретном коде springboot function aws эта функция не реализована (насколько я мог видеть).
Вы можете следовать маршруту по умолчанию, если хотите реализовать свое приложение в лямбда-выражении с помощью spring: https://github.com/awslabs/aws-serverless-java-container/blob/master/samples/springboot/pet-store.
Или ... Если хочешь, можешь попробовать на собственном опыте, но попытка: ты совсем один: https://github.com/arawn/building-serverless-application-with-spring-webflux.
Этот проект сам реализует преобразования ObjecMapper, и вы можете получить параметры из запроса: https://github.com/arawn/building-serverless-application-with-spring-webflux/blob/master/src/main/java/serverless/aws/springframework/http/server/reactive/SimpleAPIGatewayProxyServerHttpRequest.java
Уловка здесь состоит в том, чтобы создать шаблон пути в лямбда-выражении с помощью прокси (Path: '/ {proxy +}'), и запрос будет делегирован от aws mapper.
Удачи!
Проанализировав время холодного запуска с весенней загрузкой и вместе с spring-cloud-function, я выбрал путь использования только библиотек java и aws-sdk для достижения моего варианта использования. Использование APIGatewayProxyRequestEvent из библиотеки aws-lambda-java-events для получения информации о запросе и отправки настраиваемого объекта APIGatewayResponse обратно на шлюз API. В этом случае мне пришлось иметь дело со всем кодом состояния HTTP вручную. Даже с простой функцией Java холодный запуск занимает 8 секунд с памятью 512 МБ.
API Gateway упаковывает все данные входящего запроса в объект APIGatewayProxyRequestEvent, который имеет несколько атрибутов, таких как тело запроса, путь и параметры запроса или метод HTTP исходного запроса. Для вашего варианта использования вы получите три параметра пути: dept, employee и name.
Однако проблема в том, что SpringBootApiGatewayRequestHandler, который выполняет сопоставление между входящим APIGatewayProxyRequestEvent и вашей функцией, в настоящее время рассматривает только тело запроса, но не другие параметры вообще.
Надеюсь, что разработчики исправят это в будущем. А пока вы можете реализовать модифицированную версию SpringBootApiGatewayRequestHandler, которая учитывает необходимые параметры. Я написал небольшую статью который охватывает именно эту тему.
Я думаю об этом так: Spring Cloud Function - это абстракция функции, и она не должна знать о RESTful API. Вы можете использовать AWS API Gateway для преобразования параметров пути в объект JSON, а затем вызвать лямбда-функцию. Таким образом, функция не зависит от того, вызывается ли она как API или как сообщение. Лучше дизайн, больше работы.