My goal is to have a default json output when the user agent is set to anything else than json or xml. I have configured FOSRestBundle 1.1.0 as follows:
fos_rest:
format_listener: true
param_fetcher_listener: true
view:
default_engine: php
formats:
json: true
xml: true
templating_formats:
html: false
view_response_listener: force
routing_loader:
default_format: json
This works. Now I added the following configuration:
format_listener:
rules:
- { fallback_format: json, prefer_extension: false, priorities: ['xml', 'json'] }
As soon as I do that, I can no longer switch between formats by either appending ?_format=json or ?_format=xml and also the Accept header seems to be ignored, it always uses whatever I specify in the accept header.
How to configure FOSRestBundle so that it accepts json or XML via Parameter/HTTP Request header and falls back to json if the format accepted by the browser is HTML?
According to the FOSRestBundle Docs:
Note that if _format is matched inside the route, then a virtual Accept header setting is added with a q setting one lower than the lowest Accept header, meaning that format is checked for a match in the priorities last. If prefer_extension is set to true then the virtual Accept header will be one higher than the highest q causing the extension to be checked first. Setting priorities to a non empty array enables Accept header negotiations.
Also, I noticed that in the rules section, you are missing the path option. So the application doesn't know which path to apply the rules to.
Take a look at the docs I linked to above, it has an example.
Related
I work on a Electron project that uses Webpack. I use json schemas, configured like this:
module.exports = {
module: {
rules: [
{
test: /\.schema.json$/,
type: "asset/resource",
generator: {
filename: "schemas/[name].json",
},
}
]
}
}
So, if I have somewhere in my sources file some-config.schema.json that looks like this:
{
"$id": "/schemas/some-config",
"$ref": "/schemas/other-config"
}
It is emitted as http://localhost:1212/dist/schemas/some-config.schema.json. Notice 1212 — this is port number that is configured dynamically by different tools that configure the build, so I can't even know that path when I write code or schemas.
However, the $ref above doesn't work:
Problems loading reference 'file:///schemas/other-config': Unable to load schema from '/schemas/other-config': Failed to fetch.
I would want for it to load http://localhost:1212/dist/schemas/other-config.schema.json. How do I set up this reference?
The value of $ref is a URI, and not a URL. This matters because the URI is not necessarily "network addressable", aka, not a real network address.
The value of $id is an identifier only.
When a JSON Schema parser gets a value in $id which is a relative URI, if it can't determine a base URI to resolve to an absolute URI, then it should make one up. So, pretend it makes one up, or uses https://example.com.
So, when you use an $id value of /schemas/other-config, we can pretend it's prefixed with https://example.com, and so resolves to https://example.com/schemas/other-config. The same is true for /schemas/some-config.
When a JSON Schema processes the schema you've provided, it should first be using the URI resolution process, matching up references with it's index of $id values to schemas.
Essentially, set up correctly, your schema files could be located anywhere, as long as they have the correct $id values, and you've loaded them in to the implementation you're using.
I am writing a JSON schema for helm chart values.yaml wherein the yaml file is as follows:
accessID: "" // user set this value when installing individual chart
global:
accessID: "" // user set this when installing the parent which this chart is part of
How can I write JSON schema (version 7) to validate either one of this should have a non empty string.
You'll want to use an anyOf wrapped around the checks for either property. Exact matches can be done with const.
https://json-schema.org/understanding-json-schema/reference/conditionals.html
https://json-schema.org/understanding-json-schema/reference/generic.html#constant-values
https://json-schema.org/understanding-json-schema/reference/object.html
I have the following JSON:
{
"From": "stuart",
"Payload": {
"Alert": "Critical",
"Recipient": "Joe"
}
}
I want to route this based on if the field in Alert is 'Critical' or not.
I've tried RouteOnAttribute processor and also an EvaluateJson processor. Neither are working.
For RouteOnAttribute I've tried
Alerted: ${Payload:jsonPath('$.Alert'):equals('Critical')}
Then I have a relationship based on Alerted but nothing ever goes into my RouteOnAttribute processor, the queue just sits there till it fills to 10,000.
I need the full JSON to be routed, I can't lose information in the routing.
The issue is with jsonPath function works on flowfile attributes but you are not having Payload attribute associated with the flowfile.
How to add attribute to the flowfile?
After generateflowfile processor use EvaluateJsonPath processor with destination as flowfile-attribute,
Add new property
payload.alert as $.Payload.Alert
Then use routeonattribute processor add new property as
Alerted
${payload.alert:equals('Critical')}
Flow:
1.GenerateFlowFile
2.EvaluateJsonPath //extract the value and keep as attribute to the flowfile
3.RouteOnAttribute //check the attribute value
I want to define custom objects as json schema files and associated examples as separate files. I want to do something like this:
#%RAML 1.0
title: MDM
version: v1
baseUri: http://api.mdm.ishafoundation.org
mediaType: application/json
types:
Contact:
type: !include schemas/contact.json
example: !include examples/contact.example.json
But I get the following error message for the line starting with the "type:" statement - "Error: You cannot inherit from both types of different kind"
In the spec it says
External types cannot participate in type inheritance or specialization. In other words: You cannot define sub-types of external types that declare new properties or set facets. You can, however, create simple type wrappers that add metadata, examples and a description.
I'm guessing this is the problem. But I don't know what it means to create a "type wrapper". Can somebody tell me what is the best way to achieve what I want.
The RAML spec shows an example exactly like what you post here, so it should work or there's an error in the spec.
Anyway, this way of writing the RAML worked:
#%RAML 1.0
title: MDM
version: v1
baseUri: http://api.mdm.ishafoundation.org
mediaType: application/json
types:
Contact: !include schemas/contact.json
Not sure how to fit the example there but you can always add it directly to the method.
MarkLogic REST Client API's default search endpoint results in server error when using a query options node that contains more than one extract-path even though the request is successful when either extract-path is used individually within extract-document-data:
{"errorResponse":{"statusCode":500, "status":"Internal Server Error", "messageCode":"RESTAPI-INTERNALERROR", "message":"RESTAPI-INTERNALERROR: (err:FOER0000) Internal error: JSON build, unbalanced pairs: "}}
The offending paths:
<extract-path xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:FO="http://founders.archives.gov/">/tei:text/FO:metadata/FO:ProjectCode</extract-path>
<extract-path xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:FO="http://founders.archives.gov/">/tei:text/FO:metadata/FO:ShortProjectTitle</extract-path>
Only occurs when the format is JSON--XML format behaves as expected. This error can be reproduced across disparate datasets.
The entire options node:
<options xmlns="http://marklogic.com/appservices/search">
<search-option>unfiltered</search-option>
<quality-weight>0</quality-weight>
<page-length>10</page-length>
<extract-document-data selected="include">
<extract-path xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:FO="http://founders.archives.gov/">/tei:text/FO:metadata/FO:ProjectCode</extract-path>
<extract-path xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:FO="http://founders.archives.gov/">/tei:text/FO:metadata/FO:ShortProjectTitle</extract-path>
</extract-document-data>
</options>
I would simply extract the parent element FO:metadata; however, that returns a string, indicating a dependency on a parsing library (does it not?) which I would rather avoid if possible.
Any suggested workarounds are appreciated. Thanks.
There is a known bug with the inline response that should be fixed in 8.0-3.
In the interim, it should work to get the extracted fragments either as XML or as a multiplepart/mixed response (which, if the source documents are XML would also be XML).