I have a SpringBoot, JAX-RS, and Maven app. I'm using Swagger annotations to provide info on the REST service interface. It basically works, but I'm having trouble with some parameters that I expect a limited set of values. I believe I'm specifying the "#Api..." annotations correctly, and I can see the expected results in the swagger.json file, but the swagger-ui doesn't appear to do anything with that information.
My pom.xml appears to specify version 1.5.20 of the swagger artifacts.
The following is a heavily elided excerpt from the Java interface:
#GET
#Path("...")
#ApiOperation("...")
#ApiImplicitParams({
...
#ApiImplicitParam(name = "poi_types", value = "Types of locations to include",
allowableValues = "pos, wifi, country",
dataType = "string", paramType = "query"),
...
})
public Object ...(#QueryParam(...)
#ApiParam(name = ..., value = "...")
String ...) {
In the swagger.json, I see the following for that entry:
{
"name" : "poi_types",
"in" : "query",
"description" : "Types of locations to include",
"required" : false,
"type" : "string",
"enum" : [ "pos", "wifi", "country" ]
}
In the generated UI, I see the following:
I've seen somewhere some mentions of possible disconnects between the required schema and what swagger-ui renders, like perhaps requiring a "schema" element in the parameter definition that includes the "type"and "enum" properties. I tried manually changing the swagger.json to include that, but it made no difference.
Can anyone provide any background here?
Update:
I upgraded to swagger-core and swagger-annotations v1.6.2. I also tried putting "allowableValues" into an "#ApiParam" instead of just an "#ApiImplicitParam". Neither of these changes made any difference. I don't see any indication in the UI of the allowable values.
This is the changed element from the #ApiParam change:
{
"name" : "isocc2",
"in" : "query",
"description" : "Country code",
"required" : false,
"type" : "string",
"enum" : [ "en", "es" ]
}
This is how this displays in the swagger UI:
I also verified from the browser the swagger.json that it loaded, and it matches what I expected.
Just in case, I tested it in Chrome in addition to Firefox.
What else could be wrong here?
Have you tried using ?
public Object ...(#QueryParam(...)
#ApiParam(name = ..., value = "...",
allowableValues = "pos, wifi, country",)
String poi_types) {
allowableValues property works well on #ApiParam.
Related
Issue:
I am using Prismic to send data through to my website.
In Prismic I have a Type (testimonial_list) that consists of a group of content-relation fields (Prismic Type testimonials).
To query the data on the inner Types I need to access them via the document field in graphql and use inline-fragments.
I have followed as instructed here:
https://github.com/angeloashmore/gatsby-source-prismic#Query-Content-Relation-fields
Inside graphql I have managed to navigate to the testimonial data-fields (on the document field) but the document field returns null, this is where I'm stuck. I can't work out why it would return null as the content exists and the fields are clearly being found in graphql.
Info:
My project is built using Gatsby and I'm using the plugin gatsby-source-prismic v3.1.1
Here you can see I can access the correct field data and I am getting the right number of nodes returned but document is empty:
This is the JSON for the testimonial_list Type on Prismic:
{
"Main" : {
"prismic_title" : {
"type" : "StructuredText",
"config" : {
"single" : "heading6",
"label" : "Title (only used to name entry in Prismic list)",
"placeholder" : "Prismic list title (otherwise \"undefined\")"
}
},
"page" : {
"type" : "Select",
"config" : {
"options" : [ "Homepage", "Option 2", "Option 3" ],
"label" : "Website page to appear on:"
}
},
"testimonial_list" : {
"type" : "Group",
"config" : {
"fields" : {
"testimonial" : {
"type" : "Link",
"config" : {
"select" : "document",
"customtypes" : [ "testimonial" ],
"label" : "testimonial"
}
}
},
"label" : "Testimonial List"
}
}
}
}
Thank you for any help, if there is any more info I can supply to help deduce the issue please let me know.
In the end, the issue turned out to be a typo in my gatsby-config where I was requiring the schema.
It was a daft mistake but stare at something too long and these things happen I guess.
In case anybody else has a similar issue you must ensure the property names of your Prismic schemas inside your gatsby-config are exactly the same as in Prismic.
For example if your Type in Prismic is called "my_type" then you must use that exact syntax - so for example don't use "myType".
Hey it might be something related to the gatsby-source-prismic plugin
I would directly open an issue for it here if I were you: https://github.com/angeloashmore/gatsby-source-prismic/issues
https://www.hl7.org/fhir/parameters.html
is it right to add the additional parameters in extended operation or can we add the add the parameters in patient resource type . because if we have multiple values we are not able to map the patient data with the extended operation parameter.
how to add additional parameters in patient resource type???
Short Answer:
Every element in a resource can have extension child elements to represent additional information that is not part of the basic definition of the resource.
Here is the post on HL7 FHIR with detailed info and samples on Extensibility
Every element in a resource or data type includes an optional "extension" child element that may be present , So we can add the additional parameter with an extension
Eg:
{
"resourceType" : "Patient",
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/patient-citizenship",
"extension" : [{
"url" : "code",
"valueCodeableConcept" : {
"coding" : [{
"system" : "urn:iso:std:iso:3166",
"code" : "DE"
}]
}
}, {
"url" : "period",
"valuePeriod" : {
"start" : "2009-03-14"
}
}]
}]
}
Already read this but with no lucky.
All examples I've found just show how to create a single value tag like this:
{
"name" : "jvm.gc.memory.allocated",
"measurements" : [ {
"statistic" : "COUNT",
"value" : 1.98180864E8
} ],
"availableTags" : [ {
"tag" : "stack",
"values" : [ "prod" ]
}, {
"tag" : "region",
"values" : [ "us-east-1" ]
} ]
}
But I need to create a multi value tag like this:
availableTags: [
{
tag: "method",
values: [
"POST",
"GET"
]
},
My code so far:
List<Tag> tags = new ArrayList<Tag>();
tags.add( Tag.of("test", "John") );
tags.add( Tag.of("test", "Doo") );
tags.add( Tag.of("test", "Foo Bar") );
Metrics.gauge("my.metric", tags, new AtomicLong(3) );
As you can see I think I can just repeat the key but this is not the case and the second parameter of Tag.of is a String and not a String Array.
I don't think this was the real intent of authors of these metering libraries - to provide a multi-value tag for a metric.
The whole point of metrics tags is to provide a "discriminator" - something that can be used later to retrieve metrics whose tag has a specific, single, value.
Usually, this value is used in metrics storage systems, like Prometheus, DataDog, InfluxDB and so on. And above this Grafana can incorporate a single tag value in its queries.
The only possible use case of such a request that I see is that it will be possible to see the metrics value in an actuator in a kind of more convenient way, but again it's not the main point of the whole capability here, so, bottom line I doubt that its possible at all.
I don't fully understand how creating and accessing association resources works with Spring Data REST and MongoDB. I have noticed a few strange behaviours, and I am hoping to get some clarification here.
I have a simple object model where one resource type (Request) contains a list of objects of another resource type (Point). Both resources are top-level resources, i.e. have their own Repository interfaces.
I would like to be able to add a new Point to a Request by POSTing to /requests/{id}/points with a link to an existing point (as I know from this question that I can't just POST a point as a JSON payload).
Furthermore, I would like to be able to GET /requests/{id}/points to retrieve all the points associated with a request.
Here is my object model (getters/setters omitted):
Request.java
public class Request {
#Id
private String id;
private String name;
#DBRef
private List<Point> points = new ArrayList<>();
}
RequestRepository.java
public interface RequestRepository extends MongoRepository<Request, String> {
}
Point.java
#Data
public class Point {
#Id
private String id;
private String name;
}
PointRepository.java
public interface PointRepository extends MongoRepository<Point, String> {
}
Let's say that I POST a new Request. Then doing a GET on /requests gives me this:
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/requests",
"templated" : false
}
},
"_embedded" : {
"requests" : [ {
"name" : "request 1",
"_links" : {
"self" : {
"href" : "http://localhost:8080/requests/55e5dc47b7605d55c7c361ba",
"templated" : false
},
"request" : {
"href" : "http://localhost:8080/requests/55e5dc47b7605d55c7c361ba",
"templated" : false
},
"points" : {
"href" : "http://localhost:8080/requests/55e5dc47b7605d55c7c361ba/points",
"templated" : false
}
}
} ]
}
}
So I have a points link in there. Good. Now, if I do a GET on /requests/55e5dc47b7605d55c7c361ba, I notice strange thing #1. There is no points link anymore:
{
"name" : "request 1",
"_links" : {
"self" : {
"href" : "http://localhost:8080/requests/55e5dc47b7605d55c7c361ba",
"templated" : false
},
"request" : {
"href" : "http://localhost:8080/requests/55e5dc47b7605d55c7c361ba",
"templated" : false
}
}
}
But anyway forget about that for now, let's POST a point (which gets ID 55e5e225b76012c2e08f1e3e) and link it to the request:
curl -X PUT -H "ContentType: text/uri-list" http://localhost:8080/requests/55e5dc47b7605d55c7c361ba/points
-d "http://localhost:8080/points/55e5e225b76012c2e08f1e3e"
204 No Content
That seemed to work. Ok, so now if I do a GET on http://localhost:8080/requests/55e5dc47b7605d55c7c361ba/points, I expect to see the point I just added, right? Enter strange thing #2, I get the following response:
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/requests/55e5dc47b7605d55c7c361ba/points",
"templated" : false
}
}
}
So at this point I realise I've done something wrong. Could somebody please explain to me what's happening here? Do I have a fundamental misunderstanding of the way SDR is working? Should I even be using DBRefs? Or is this simply not possible with MongoDB?
Thanks in advance, and sorry for the long question!
Edit
The Points are in fact being added as DBRefs (verified by looking at the db manually), but it appears that SDR is not giving them back. If I explicitly ask for http://localhost:8080/requests/55e5dc47b7605d55c7c361ba/points/55e5e225b76012c2e08f1e3e, then I get the following response:
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/points/55e5e225b76012c2e08f1e3e",
"templated" : false
},
"point" : {
"href" : "http://localhost:8080/points/55e5e225b76012c2e08f1e3e",
"templated" : false
}
}
}
Which is also strange... where is my Point.name?
Both aspects are caused by a glitch in Spring Framework 4.2.0, which Spring Boot 1.3 M4 has upgraded to which causes Spring Data RESTs custom serializers not applied in some cases. This is already fixed in Spring 4.1.2. To upgrade your Gradle project to that version, upgrade to the Boot plugin to a 1.3 and then fix the Spring version to 4.2.1 using the following declaration:
ext['spring.version'] = '4.2.1.RELEASE'
Make sure you properly initialize the collection with an empty one as a null value will cause 404 Not Found being returned. An empty list will produce correct HAL output.
Generally speaking association resources should be used with already existing resources, esp. with Spring Data MongoDB there's no other choice as it doesn't have persistence by reachability. I.e. you'd need to persist the related instance first (aka. POST to it's collection resource and get a Location header back) and the assign the just created resource (aka. PUT or POST the just obtained Location to the association resource), which seems to be what you're doing.
I am using Spring Framework 4.1.0 and Spring HATEOAS 0.16.0 to develop both a Spring web application and a Spring test client for that application.
The test client has a statement like:
ResponseEntity<Resource<Calculation>> response = restTemplate.exchange(
calculationsUri,
HttpMethod.POST,
new HttpEntity<Calculation>(calculation),
new ParameterizedTypeReference<Resource<Calculation>>()
);
...wherein Calculation is a POJO with Jackson annotations (for example, #JsonProperty).
Without CURIEs, that RestTemplate.exchange() invocation succeeds: response.getBody().getLinks() returns a non-null non-empty instance of List<Link>.
My web application has non-standard link relations, for example, "sub-calculations". I want to use CURIEs.
With CURIEs, that RestTemplate.exchange() invocation fails: The response-deserialization code throws org.springframework.http.converter.HttpMessageNotReadableException, caused by com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
'Could not read JSON: Unrecognized field "name" (class org.springframework.hateoas.Link), not marked as ignorable (one known property "href"])'
In particular, Jackson fails to deserialize the CURIE(s) from the _links map in the response JSON to the List<Link>-typed field org.springframework.hateoas.ResourceSupport.links. The response JSON looks like:
{
"_links" : {
"self" : {
"href" : "..."
},
"myNamespace:sub-calculations" : [ {
"href" : "..."
}, {
"href" : "..."
} ],
"curies" : [ {
"href" : ".../{rel}",
"name" : "myNamespace",
"templated" : true
} ]
}
}
How may I use RestTemplate.exchange() to obtain a resource whose HAL+JSON ("application/hal+json") representation uses CURIEs?
looks like the library simply doesn't support the name field of HAL link object https://datatracker.ietf.org/doc/html/draft-kelly-json-hal-06#section-5.5 ...doesn't really have anything to do with CURIE's. You should open an issue with that library to support all the fields of HAL link objects.
As far as CURIE #CCCV in your example they key is AWALYS myNamespace:sub-calculations no matter if CURIE is present or not. CURIE just lets you dereference to a URL that SHOULD link to documentation. It's kinda weird, and i see implementations get it wrong all the time thinking the URI is what matters. see https://groups.google.com/d/msg/hal-discuss/lt0CnC3eev4/YinN1Us54KcJ i'm not saying i agree with it..but that's how it's supposed to be