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.
Related
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.
I created a RAML file in API Design, then deployed in API manager and implemented in API runtime manager. It is clear no issues now.
Now i got change in raml file. I did changes in API Design and published into exchange with v2.
The problem here is how to import the v2 API into API manager ?
after importing the new api do i need to add all policies applied on v1 API to v2 API again ?
or is there any automatic option ?
I don't find any options in API manager, please help me..,
Yes, we need to apply policies again. Even when there is the same API version have 2 instances.
If you do not have major change then you can just go to action and upgrade to next assent version of the same API. Else you need to apply policies.
Ranveer
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'm new to this api documentation era.
Vising this api documentation, I get to post and query data. I understand that's a demo api documentation with swagger.
But what happens with real world API documentation? do I have a documentation in demo.api.myawesome.com and actual api on api.myawesome. com using different data stores?
But again digging deeper, I got to find out that an api can be self documenting using swagger libraries. This seems like both api and documentation are using the same data store which can't be the case.
What am I missing here?
From the Swagger website:
Swagger is a set of rules (in other words, a specification) for a format describing REST APIs. The format is both machine-readable and human-readable. As a result, it can be used to share documentation among product managers, testers and developers, but can also be used by various tools to automate API-related processes.
So yes, it uses the same "back end" as the actual API. It's just visualizing it, allowing you to interact with it via the Swagger UI.
If you mean Swagger UI - the "try it out" button sends requests to the server specified by the host property in your spec. If host specifies your production server, requests will be sent to production; if it points to a sandbox, "try it out" will use the sandbox. You may have a version of the spec for internal use that points to production, and a public version that points to sandbox.
Note that Swagger supports authentication as a way to ensure that only authorized users (e.g. your actual customers with valid credentials or API keys) can make API calls.
You can omit host from the spec to disable the "try it out" functionality - this way you can still have the API docs, just without the interactive part.
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.