In mantle REST API, partial updates are done with PATCH method. however tomcat does not support PATCH method yet.
My question is how the PATCH method is handled in default deployment (and most of deployment is done with Tomcat)?
Related
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 have a .NET Core 3.1 Web API that I want to add XSRF protection to. So I now require an antiforgery token in an X-XSRF-TOKEN HTTP header on all of my endpoints as described here. JavaScript clients get a token by hitting the /antiforgerytoken endpoint, which sets an XSRF-TOKEN cookie containing the token. This all works fine, but as one would expect, the "Try it out!" feature in Swagger UI no longer works since the requests are missing the X-XSRF-TOKEN HTTP header. Is there a way to have SwaggerUI automatically call the /antiforgerytoken endpoint and include the token in the request being executed?
On Swagger UI, this can be supported by setting a requestInterceptor on the configuration which is a function that intercepts and modifies outgoing requests, including "Try it out" requests. See this comment in Swagger UI repo and the README on Swagger UI configuration.
However, Swashbuckle.AspNetCore.SwaggerUI does not yet support setting requestInterceptor in C# as of the latest stable release (5.6.3). There is this PR that added support for interceptors, and it has been merged but not yet released. So if you are using Swashbuckle.AspNetCore.SwaggerUI, your options for now is to wait for the next release, or build from source a local version before the next official release.
I am looking into using the Swashbuckle.AspNetCore v4.0.1 NuGet package in my ASP.Net Core project to generate a SwaggerUI documentation endpoint for my web API that will be used by various teams internal to my company. My API consumes and emits a handful of message bus events and commands that I'd like to include as part of that documentation.
Are there any custom settings in Swashbuckle's middleware that would allow me to document input/output objects not associated with API endpoints?
That the endpoint emits a a service bus event is an internal implementation detail and should not need to be documented.
If you want to provide documentation for an endpoint you can write XML documentation and configure Swashbuckle to expose that documentation using the IncludeXmlComments method.
Microsoft explains how to configure Swagger this way in their Get started with Swashbuckle and ASP.NET Core article.
When should we use API Proxy against API AutoDiscovery. After implementing both, I found AutoDiscovery can also apply policies, analytics which API Gateway does, only thing is I cannot use a different url if using AutoDiscovery. Main advantage of API Proxy would be if my Gateway application and Mule Implementation Project is in different subnet, so if we are my Gateway server is compromised, no one can get to my implementation network.
But if both interface and implementation is in the same network, and purpose is just to call a REST Endpoint, should we not go with API AutoDiscovery.
Problems with Mule API Gateway Proxy
No defined way of Exception Handling, if we are not able to reach the Implementation Server.
No defined way of moving the Proxy Application across environments (CI/CD)
Extra HTTP Hops, can be acceptable if the above 2 issues have a defined way
Mule API AutoDiscovery
Since this is in the Mule Application, standard Exception Handling.
CI/CD is defined as it is the Mule Implementation Project.
No Extra HTTP Hop.
Only thing here is, we cannot change the implementation URL, that is only tightly coupled thing.
Can someone provide insight on when should we go for API Gateway vs AutoDiscovery. Also currently is there a way of doing Exception Handling in API Gateway Project and also CI / CD ?
API Autodiscovery is required if you plan to apply/unapply a policy to a particular endpoint, and/or take advantage of usage statistics in the context of API Platform. Api Autodiscovery is kind of metadata that links a HTTP(s) listener to its counterpart API version on API Manager.
For example:
<api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
</api-platform-gw:api>
<flow name="basic.path">
<http:listener config-ref="a.http.config" />
<set-payload value="Endpoint successfully called." />
</flow>
Autogenerated Mule Proxies do have autodiscovery defined. You can also develop your own project and define the corresponding autodiscovery either by using the Studio UI, or handling the XML config directly.
The proxies are mean to be used in the case that your implementation backend is not a Mule application (for example, an existing REST based API hosted in a Tomcat server). You can enrich the logic with custom exception handling among other things on the Mule side. If you'd like better exception handling on the implementation backend, you will have to implement it there.
If your implementation backend is a Mule based application, using a proxy is not required. For most use cases, adding the corresponding autodiscovery element in the configuration file will do the trick.
I need to write a Java web application to call a function Meteor APP. One way is through API call. Are there any other means to call Meteor function from 3rd party application.
Thanks
Murali
It all depends on what your requirements are, how your Meteor app is structured, and what sort of integration you desire.
If you are wanting your Java web application to be able to natively call Meteor methods or subscribe to publications, then you will have to use a Java DDP Client to do this. Fortunately, there is at least one documented Java DDP client that you can use for this (and probably many others out there is you search). For your reference, here is a compiled list of DDP clients for other languages/technologies.
If on the other hand you don't want to interface with you meteor app using DDP, then you could always implement a REST API in your meteor app. There are several packages available to do this, but I would highly recommend the simple:rest package.
This package automatically creates a REST API for all your existing publications and methods without any extra code (just simply add the package to your meteor app). If you do need to configure or modify the REST API, the package also provides several options that you can use in your publication or meteor method definition. The package also enforces all your app's security rules and authorization.
For example, if your app had a publication called openTasks, then the corresponding REST endpoint would be.
GET /publications/openTasks
There are quite a few packages at https://atmospherejs.com/?q=rest that can expose your Meteor methods as RESTful API points which your Java app can consume.