Our system needs to return several KPIs grouped in different topics:
Census:
citizens (number of inhabitants)
citizens without any studies
...
Information desk
Phone response time
Mail response time
...
Tax
Online payments
Window payments
...
To my understanding, it would make sense to have an entity for each topic and each KPI being a KeyPerformanceIndicator attribute. eg: This could work similar to:
{
"description": "Census Information system",
"dataProvided": {
"entities": [
{
"idPattern": ".*"
}
],
"attrs":[ //THIS SEEMS AN INTERESTING APPROACH, BUT SADLY ALSO INVALID
{
"name": "citizens",
"type": "KeyPerformanceIndicator"
},
{
"name": "citizens_without_studies",
"type": "KeyPerformanceIndicator"
},
//...
]
},
"provider": {
"http": {
"url": "http://myhost/v2/census"
}
}
}
(TL;DR: "attrs" supports strings only, so can't return complex/data modeled types, like KPI)
Setting this happy idea aside, what it would be a good approach to solve this?
Must each KPI be an entity?
Is NGSI-LD what I'm looking for?
I think your case can be solved in NGIv2. Let my try to explain.
Must each KPI be an entity?
Yes. That's the usual way of modelling KPIs according to the KPIs datamodel. Each KPI is modeled as an entity of type KeyPerformanceIndicator.
Can KPIs be categorized?
Yes. You can use the category attribute to do that.
For instance, you can have an KPI "Online payments" of category "Tax Information" modeled this way:
{
"id": "OnlinePayments",
"type": "KeyPerformanceIndicator",
...
"category": ["taxInformation"],
...
}
Note that category is an array, so a given KPI could belong to more than one category (although in your use case it seems that each KPI belongs to exactly one category so you don't need this feature)
How can I get KPIs that belong to a given category?
You can use regular Orion Context Broker filtering features for that. For instance, to get all KPIs in category taxInformation you could use this key:
GET /v2/entitites?type=KeyPerformanceIndicator&q=category:taxInformation
or this expression in subscriptions:
{
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "KeyPerformanceIndicator"
}
],
"condition": {
...
"expression": {
"q": "category:taxInformation"
}
}
},
...
}
If what you are trying to accomplish is to offer an NGSI interface for your KPI data, you can just create your own adaptor on top of your database that offers a REST interface compliant with NGSI-LD and such service can just return entities of type KeyPerformanceIndicator. Then, you can federate it to a Context Broker with a simple registration i.e. for entities of type KeyPerformanceIndicator. And that's all.
The usage of Linked Data would be recommendable as well, so I would go for NGSI-LD, as it has been officially endorsed by ETSI.
Related
We are during design of our REST-API and we are wondering in what form REST endpoint should return data?
We have an endpoint that returns so-called "identity" objects that have different attributes.
Each 'identities' has unique string eg. UUID#cf684c35-200e-4936-8b63-e6e51b6e3569.
We are wondering which format the developers are more used to?
Like this below:
{
"UUID#cf684c35-200e-4936-8b63-e6e51b6e3569": {
"validity_date": 1608591121,
"visibility": "private"
},
"RFID#cf684c35-200e-4936-8b63-e6e51b6e3570": {
"validity_date": 1608591123,
"visibility": "public".
}
}
or
{
"results": [
{
"identity": "UUID#cf684c35-200e-4936-8b63-e6e51b6e3569",
"validity_date": 1608591121,
"visibility": "private"
},
{
"identity": "RFID#cf684c35-200e-4936-8b63-e6e51b6e3570",
"validity_date": 0,
"visibility": "1608591123"
},
]
}
What is your opinion?
TL;DR I recommend to use a list of objects (your second approach).
Let's take your objects to a more obvious example of users with an id and a name:
{
1: {
"name": "Michal"
},
2: {
"name": "Thomas"
}
}
[
{
"id": 1,
"name": "Michal"
},
{
"id": 2,
"name": "Thomas"
}
]
Both approaches can be used, I don't see any difference from the API-level itself.
But let's consider how an application might provide or consume such data:
fetching a database table of users (e.g. whose birthday is next week)
showing a table of users (e.g. user name and birthday)
processing the monthly salary to employees
All three examples use a list of users, which is the second approach. Since many applications operate on a list of entities, that's a common sense for APIs.
I think that it [] is better than it { "results": [] }.
Said it, on my opinion the 2nd is better because of [on some languages] is easier to map it than to map the 1st.
I'm creating a procedure in a transaction bundle and add practitioners as actors to the performers collection, having different functions. As far as the practitioners references are unique, all is fine. But when I'm trying to add a practitioners twice, with a different functions, an exception is thrown:
Can not process entity with ID[urn:uuid:7165d406-da59-4436-aa93-372ca882c4e5], this is not a valid FHIR ID
I found this message in HAPI FHIR unit tests, but in my case, the uuid seems to be fine. But maybe only one uuid is replaced with the id of the created practitioner.
I'm also not sure, whether this is the correct way for what I want to achieve.
I also tried to add the practioner only once and then add the second role to function.coding. But the resulting entry looks for me kinda strange:
performer": [
{
"function": {
"coding": [
{
"system": "http://somewhere/performer-role",
"code": "88888888"
},
{
"system": "http://somewhere/performer-role",
"code": "99999999",
"display": "Role-2"
}
],
"text": "Role-1"
},
"actor": {
"reference": "Practitioner/2925"
}
},
I'm fairly new to Fhir. Does anybody knows what's wrong here ?
And, what's the recommended practice, to have one performer/actor in to different roles ?
Thanks in advance
P.S. I'm using HAPI FHIR 4.0
Multiple coding repetitions would be used to convey translations - so you're saying that 888888888 and 99999999 are two different codes that represent the same role. If you want to indicate that the same Practitioner had two different roles, then you need to have two different performer repetitions. E.g.
perfomer: [
{
"function": {
"coding": [ {
"system": "http://somewhere/performer-role",
"code": "88888888"
}]},
"actor": {
"reference": "Practitioner/2925"
}
}, {
"function": {
"coding": [ {
"system": "http://somewhere/performer-role",
"code": "99999999"
}]},
"actor": {
"reference": "Practitioner/2925"
}
}
]
So let's say I have a resources called articles. These have a numeric id and you can access them under something such as:
GET /articles/1 for a specific article.
And let's say that returns something like:
{
"data": {
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON:API paints my bikeshed!",
"body": "A bunch of text here"
}
}
}
Now my question is how to handle a request to GET /articles. I.e. how to deal with the request to the collection.
You see, accessing the body of the article is slow and painful. The last thing I want this REST API to do is actually try to get all that information. Yet as far as I can tell the JSON API schema seems to assume that you can always return full resources.
Is there any "allowed" way to return just the IDs (or partial attributes, like "title") under JSON API while actively not providing the ability to get the full resource?
Something like:
GET /articles returning:
{
"data": [
{
"type": "article_snubs",
"id": 1,
"attributes": {
"title": "JSON:API paints my bikeshed!"
}
}, {
"type": "article_snubs",
"id": 2,
"attributes": {
"title": "Some second thing here"
}
}
]
}
Maybe with links to the full articles?
Basically, is this at all possible while following JSON API or a REST standard? Because there is absolutely no way that GET /articles is ever going to be returning full resources due to the associate cost of getting the data, which I do not think is a rare situation to be in.
As far as I understand the JSON API specification there is no requirement that an API must return all fields (attributes and relationships) of a resource by default. The only MUST statement regarding fields inclusion that I'm aware of is related to Sparse Fieldsets (fields query param):
Sparse Fieldsets
[...]
If a client requests a restricted set of fields for a given resource type, an endpoint MUST NOT include additional fields in resource objects of that type in its response.
https://jsonapi.org/format/#fetching-sparse-fieldsets
Even so this is not forbidden by spec I would not recommend that approach. Returning only a subset of fields makes consuming your API much harder as you have to consult the documentation in order to get a list of all supported fields. It's much more within the meaning of the spec to let the client decide which information (and related resources) should be included.
The "attributes" object of a JSON-API doc does not need to be a complete representation:
attributes: an attributes object representing some of the resource’s data.
You can provide a "self" link to get the full representation, or perhaps even a "body" link to get just the body:
links: a links object containing links related to the resource.
E.g.
{
"data": [
{
"type": "articles_snubs",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"links": {
"self": "/articles/1",
"body": "/articles/1/body"
}
},
{
"type": "article_snubs",
"id": "2",
"attributes": {
"title": "Some second thing here"
},
"links": {
"self": "/articles/2",
"body": "/articles/2/body"
}
}
]
}
I`m very new to JS/APIs/JSON.
I`ve got an API I built using deployd, a great tool that allows to to quickly set up an API.
My API called "app" has two resources zips and people. Each entry/object in zips has only one property zipcode. Each people has the properties name and phonenumber.
I want to figure out a way to have people be associated with various zipcodes. Either one or many if necessary. This would, as I understand, involve adding a property to people such as assoczipcodes and using a relationship model to indicate with zipcodes are related.
I've done some research here about how a relationship is structured but I simply don't understand the syntax and format.
Q: What datatype is correct for associzipcodes?
Q: What do I enter into each assoczipcodes to indicate which zips are related?
Cristik's answer appears to be outdated. According to the current documentation, you'd want to nest the relationship like this:
{
"type": "people",
"id": "1",
"attributes": {
"name": "John Doe"
},
"relationships": {
"zipcodes": {
"links": {
"self": "http://myserver.com/people/1/zipcodes"
}
}
}
}
Based on the contents from the Resource Relationships section, the simplest approach would be to return an URL for the relationship, and have that URL return all information needed:
{
"type": "people",
"id": "1",
"name": "John Doe",
"links": {
"zipcodes": "http://myserver.com/people/1/zipcodes"
}
}
What is the convention,should array of objects in json be pluralized or not
i.e
{
"releases": [
{
"id": "0b405ea7-8785-402f-bcf7-d55f5000dc3e",
"title": "Wintertunes"
},
{
"id": "7eb37a3a-646d-4501-a373-e9071186b88d",
"title": "Adventure Magic Supreme Journey Music"
}
],
}
versus
i.e
{
"release": [
{
"id": "0b405ea7-8785-402f-bcf7-d55f5000dc3e",
"title": "Wintertunes"
},
{
"id": "7eb37a3a-646d-4501-a373-e9071186b88d",
"title": "Adventure Magic Supreme Journey Music"
}
],
}
I believe Google JSON Style Guide is a good source for this kind of doubt.
Arrays usually contain multiple items, and a plural property name reflects this.
Also, the strongest argument for the plural form would be the direct object mapping you get from JSON.parse(). You probably want your Javascript code to deal with pluralized array objects.
Though, in case you have a million such entries - with no compression - that extra 's' will for sure produce some significant bloat :P
In the absence of any strong opinion decided to pluralize it