What exactly are resources and resource resolvers. Can you please elaborate the same and essential terms relating to it?
Wanted to know how resource resolver works and if possible it's usage with an example.
A high level view can be found on https://sling.apache.org/documentation/the-sling-engine/resources.html. Sling is essentially the core of AEM.
The easiest way to use a ResourceResolver in a servlet is getting it from SlingHttpServletRequest.html#getResourceResolver. The resolver needs to have the appropriate repository rights to access the resource, but every node under /content should be accessible.
You could than adapt the node to the appropriate component and get a JSON representation by Jackson mapper.
Related
I have undertaking a master thesis project that uses the openapi.yaml files to auto generate test for REST-api web-services - This has lead me to host a local instance of gitlab, so that I can run the tool I am working on, on gitlab. For that to happen I need the .yaml files containing the documentation for the API calls. Such files are found within in the gitlab source-code, but the call does not seem to work.
Some calls work, namely:
http://localhost/api/v4/version
http://localhost/api/v4/users
http://localhost/api/v4/projects
http://localhost/api/v4/groups
all returns meaningful JSON.
the problem is that a lot of the calls within the documentation does not work (returns a "404 not found"), namely:
http://localhost/api/v4/metadata
http://localhost/api/v4/projects/{id}/access_tokens
and more calls specified in the documentation.
The problem is that a lot of the calls that work are not documented (all of the above except the 'version' call). I have really tried to look for an alternative openapi.yaml files, but with little success and I am also puzzled to why the one left in the actual source-code does not contain meaningful documentation. Have I overlooked something? I am currently using postman and providing a sudo authentication-token.
Thanks in advance - I must surely have overlooked something!
Currently I have tried to look for an alternative openapi.yaml both by googling and be browsing swaggerhub.com. I Have look at the documentation pages for gitlab, but I have not found anything I did not already have.
Unfortunately, at this time of writing, GitLab does not provide an OpenAPI spec for all of its API. Only a very small part of the API is documented in openapi.yml. There is an open issue that is tracking this improvement.
For now, the online API docs are going to be your best source of information available on using the GitLab API.
As for your problem of getting 404 responses, the most common cause of this is that the credentials you are using do not have permissions to the project/feature you are trying to access or you are not using a proper authentication method. Also keep in mind some features of the API require an appropriate license entitlement.
I am using ABP v3.3 on ASP.NET Core 3.1 in a microservice environment.
We are wanting to prefix our microservice routes with the service name.
E.g, accounting service would be:
/accounting/api/invoices
/accounting/api/payments
This is fine with our own controllers as we can define the route with route attributes. E.g [Route("accounting/api/invoices")]
However for internal abp routes like
/api/abp/api-definition
where the controller is defined in the Abp module with these route attributes already applied, how do we go about adding this prefix?
I can’t find anywhere in the documentation anything relating to this, except for the case of conventional controller creation which is not applicable here.
The above is to support the scenario where all microservices are behind an internal load balancer, and all /accounting routes should forward to this single service. This is troublesome currently when using IHttpClientProxy for service-to-service requests, as the /api/abp/api-definition request needs to be forwarded to the specific microservice.
The only alternative approach I have found is to set root paths for all services as http://<loadbalancer>/<servicename>, and then in each service add the line
app.UsePathBase("/accounting")
which strips the above path from the requests to enable route matching.
This however does cause additional issues with the generated Swagger docs from showing this additional route path, which can become confusing.
Any help appreciated
yes but not recommended because you need to replace several code parts.
for example
https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Http.Client/Volo/Abp/Http/Client/DynamicProxying/ApiDescriptionFinder.cs#L94
https://github.com/abpframework/abp-samples/blob/master/MicroserviceDemo/gateways/BackendAdminAppGateway.Host/BackendAdminAppGatewayHostModule.cs#L126
https://github.com/abpframework/abp/blob/dev/modules/blogging/src/Volo.Blogging.HttpApi/Volo/Blogging/BlogsController.cs#L14
I´m working in a scientic work and I need to use the openthread simulator.
By the documentation (above) to set the coap resource is necessary to use the uri-path, does anyone have an examle how to do that ?
Thanks in advance
Ricardo
https://github.com/openthread/openthread/blob/master/src/cli/README_COAP.md#resource-uri-path
resource [uri-path]
Sets the URI path for the test resource.
coap resource test-resource Done > coap resource test-resource Done
Sets the URI path for the test resource.
coap resource test-resource
Done
coap resource test-resource Done
The URI-Path to the path component of the URI. If you need the CoAP server to read data from a file when responding to a CoAP Request, you will need to write the code to do so. You can reference src/cli/cli_coap.cpp for example code. In particular, you can see where the resource content is retrieved in src/cli/cli_coap.cpp#L630.
Documentation for DS.ActiveModelAdapter is exists only for 1.13 (for 2 - 404:
https://api.emberjs.com/ember-data/1.13/classes/DS.ActiveModelAdapter
So, it looks like it's moved out from DS:
https://github.com/ember-data/active-model-adapter
We have ember-data 2.13.2 and it's working fine with active-model-adapter
But we got some issues with the bump to ember-data 2.14.11 with nested behavior
The big issue here is to rewrite the backend part.
We also may use RESTAdapter:
https://www.emberscreencasts.com/posts/113-restadapter-vs-jsonapiadapter-vs-activemodeladapter
but it looks like ember way is JSONAPIAdapter way:
https://api.emberjs.com/ember-data/release/classes/JSONAPIAdapter
So, generally, the question is: what way is better for ember-upgrade?
keep backend API and maintain active-model-adapter
rewrite backend API and migrate to JSONAPIAdapter (with data/relationships approach)
rewrite backend API and migrate to RESTAdapter
keep backend API and implement custom serializer to change on the fly input/output to use JSONAPIAdapter or RESTAdapter (pick best) logic on FE (maybe it's some crazy way, but it's just to ask)
Note: backend API on RubyOnRails
A rewrite of your backend is not needed. Ember Data is flexible enough to handle all REST APIs that follow some convention among their endpoints.
Let's have a look on your specific use case.
ActiveModelAdapter and ActiveModelSerializer were deprecated in Ember Data 1.13 and removed in Ember Data 2.0. But the logic itself is still available through active-model-adapter package.
All that package does is providing a customization of Ember Data's build-in RestAdapter and RestSerializer packages. If you ignore the in-source documentation it's actually not much code. You can find it in the addon/ folder of active-model-adapter package.
So even if this package would not be available you could still customize RestAdapter and RestSerializer in the same way to support your backend as is.
I have a device for which I am implementing an HTTP API and defining it via OpenAPI 3.0.
The following paths are defined:
/scan/inventory/start
/scan/location/start
/scan/direction/start
This API is designed to run on various devices, but not all of them implement the location or direction feature, but all do implement the inventory feature. The available features can be queried by GETing the /scan path.
For a device that does not support location my team has been waffling on the error code to return if someone attempts to use it. We want to provide useful feedback when this happens, so 404 seems ruled out, especially since the path is documented in our API. After reading and re-reading RFC-7231 and various summaries of it, 501 or 403 seemed like good choices.
At first, "501 Not Implemented" seemed like a good choice, but the 5XX class of errors seems to suggest a more serious server error.
Since we want to provide feedback, "403 Forbidden" seems good and puts the onus on the client for accessing a bad path.
I'm sure part of the problem is that we're attempting to use a specification (HTTP) that was not necessarily designed for arbitrary APIs.
What would you suggest we do?
This is a pretty straightforward 404.
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
403 isn't right, since that indicates that the user isn't "authorized" to access that resource. It implies that the issue lies on the client side. But in this case there simply is no resource.
501 isn't right, since that "indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource." In this case the server has no problem supporting the request, it's just that the resource doesn't exist.
Note that "server" refers to the web server. The issue isn't whether or not your application as a whole supports some bit of functionality, it's whether the web server is capable of handling the HTTP request it was sent. It's not appropriate to use HTTP status codes to indicate that kind of high-level application state.
Also note that the status code isn't just a private contract between your application and its users. All actors in the web stack—loggers, intermediate caches, browsers, etc.—might change their behavior depending on the status code. That's why it's important to reserve things like 5xx for actual server errors.
To summarize, since the resource at that URI doesn't exist, the best way to provide useful feedback is to return a 404. If you want to distinguish between features that are never supported and those that are simply unsupported for that device you should use a mechanism other than the status code. Fortunately you're off to a good start by listing the available features at /scan.