Microsoft offers a RESTful API for Azure App Configuration with the documentation at:
https://learn.microsoft.com/en-us/rest/api/appconfiguration/configurationstores/list
I have defined some features using Feature Manager in an instance of App Configuration. When I use the above API, it just gives me a list of App Configuration. I was wondering if there is an API for listing the features defined in App Configuration. I am building a service and I need to be able to query it programmatically.
The key-values present in your instance of App Configuration can be accessed through the data-plane API detailed here. The API docs you linked to are control-plane docs for creating/managing App Configuration instances, rather than working with the data inside of them.
Features in an App Configuration instance are key-values that follow specific conventions detailed here. To work with them programmatically, you can use the key-values API and follow the feature flag conventions for key-values.
Related
I am developing a Teams application with AspNetCore and React with typescript.
I would like to add the messaging extension functionality to my app. I have tested the available samples for Action based Messaging extension from here - https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/csharp_dotnetcore/51.teams-messaging-extensions-action
I could run this sample and successfully connect to the bot I created in my Azure resource group.
Since I already have a Teams project created, I want to know if I can just add the code that makes the messaging extension work from this sample or do I need to have a separate project just for running the bot and messaging extension?
Note- I do not have a Bot implementation in my original project.
It's definitely possible to combine them into the same project, you just need to make sure the endpoints all work correctly. The bot has, by convention, an endpoint at something like "/api/messages", but this is just a convention - you can use that or anything else you like, as long as you configure it properly in the Azure Bot registration so it knows what endpoint is for your bot, compared to the rest of the ASP.Net project.
I got the task to integrate the systems of our old shop to Shopware 6. So I have to deal with the Admin API. The documentation says:
The Admin API is designed in such a way that all entities of the
system can be read in the same way. Once an entity is registered in
the system, it can be written and read via API
https://developer.shopware.com/docs/guides/integrations-api/admin-api/reading-entities
How do those entities work? Is there a list/documentation of all default entities? Do I have to register the entities myself?
Shopware 6 API documentation sources
There is a public Shopware 6 API documentation (admin API and store API) available at
For Shopware >= 6.4: https://shopware.stoplight.io/
All versions: https://swagger.docs.fos.gg/
Local Documentation
Otherwise you can use the /api/v{version}/_info/swagger.html as pointed out by Valerii.
Be advised that starting from Shopware 6.4, the API version is no longer used in requests. So as per documentation you have to open something like
https://your-shop-url.invalid/api/_info/swagger.html
Make sure you have set
APP_ENV=dev
in your .env and use this only locally and not on a publicly accessible server.
The advantage of using the local documentation is, that you will also see endpoints which are introduced by additional extensions.
Reverse engineering instead of documentation
In addition you can always check the network tab of your browser when doing the intented action in the Shopware admin panel, and learn about the necessary requests.
You don't need to register "default" entities that are provided by Shopware core. But if you define your own custom entity you have to register it as a service. You can get a list of entities that are registered in the core using /api/v{version}/_info/swagger.html endpoint which generates swagger UI docs.
I am currently looking at implementing feature toggles using ff4j for our application. We want to have a remote central config app which will hold all the features in it and the applications will talk to this central config app via REST to get the features. We will not be able to leverage Spring Cloud Config or Archaius for this purpose.
I went through the documentation and it seems there is a support for HttpClient (https://github.com/ff4j/ff4j/wiki/Store-Technologies#httpclient). But I couldn't find any sample for the same. Can someone please let me know if I can leverage this method to build my feature store from a REST endpoint. Also, I would appreciate if someone could point me to a sample of this.
This is a common pattern.
A component holds the Administration UI (console) and the REST API. You can call it the "Admin Component". For security reasons It may be the only component to have access to persistance unit (any of the 15 DB implementation available)
For the "admin component" HERE is sample using standAlone spring-bppt application using JDBC DB, and HERE you find a simple web application.
The REST API can be secured using credentials user/password and/or API Key. More information HERE
All microservices access the REST API as clients and request feature store. You will need the dependency ff4j-webapi-jersey2x or ff4j-webapi-jersey1x that hold the client http> Then you can define the store using :
FeatureStoreHttp storeHTT = new FeatureStoreHttp("http://localhost:9998/ff4j");
Warning : Please consider using cache to limit overhead introduce by accessing the REST API at each feature usage. More info on cache HERE
I am using serverless framework to build a REST API. I have reached the 200 limit stack size and read about the multiple approaches to circumvent it. The most common approach is to split the stacks in a "microservices fashion", where each stack handles a particular set of resources that make sense together.
Because of how serverless works each of those services would create a new api gateway for itself and then, as explained in this blog post, a shared domain can be setup between them so all endpoints can be accessed through the same base url.
Even though this is a valid solution I would really like to be able to work with a single API gateway resource shared between the different stacks, so I don't have to decide upfront a separation of concerns between the different components of my api. Is this possible?
This feature has been recently added to serverless. Documentation is available here.
Essentially the apiGateway to be used in a serverless file can be configured through a config option inside "providers".
provider:
...
apiGateway:
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework
restApiRootResourceId: xxxxxxxxxx # Root resource, represent as / path
This feature was introduced by this pull request and is available from serverless version 1.26.
I have created some APIs in API management layer, which are essentially proxies between the calling client and an underlying web api.
I did this by importing the swagger file of the underlying API, and then adding the newly created API to a Product, repeating this for each separate proxy that I needed. This means then that the underlying API could be called but not without the subscriber key of the product that the newly created API was attached to.
Is it possible to do something similar with API apps, i.e. creating API apps using just the swagger file from the underlying API in the azure portal, that act as proxies between the calling client and an underlying web api (as below)?
Do you mind expanding on why do you need to have API Apps acting as proxies?
I am not aware of such capability for API Apps specifically. There are Swagger-based code generation tools available, for example on http://swagger.io/open-source-integrations/. So perhaps you will be able to find something that would work for you.