By running Privileges.list on google admin sdk we get a JSON looking like this:
{
"kind": "admin#directory#privilege",
"etag": "\"JCPRxFaiNR1s5TJ6ecIH8OpGdY4efiOYXbIB65itOzY/l3mP5LVwu5mUzpHpCwuZ6dUl8sQ\"",
"serviceId": "00tyjcwt49hs5nq",
"serviceName": "play_for_work",
"privilegeName": "MANAGE_EXTERNALLY_HOSTED_APK_UPLOAD_IN_PLAY",
"isOuScopable": false
},
{
"kind": "admin#directory#privilege",
"etag": "\"JCPRxFaiNR1s5TJ6ecIH8OpGdY4efiOYXbIB65itOzY/0pXB8E7QTg03vLTGIizjP3RJ_KM\"",
"serviceId": "02w5ecyt3pkeyqi",
"privilegeName": "MANAGE_PLAY_FOR_WORK_STORE",
"isOuScopable": false
}
Where the second privilege doesn't contain a serviceName, just a serviceId.
What can we do with that serviceId? Is there a way to find the associated service using it?
I've inquired with some Google sources and it appears that they are aware that some serviceNames are not available, and there's no public list available. It may be confidential for some reason or they just prefer to keep it internal for now and they may or may not have plans for it in the future. Even the privileges.list API documentation mentions that the serviceId is an "obfuscated ID of the service", so we can at least tell that services and their IDs are important to them. This is a common practice.
The good thing is that, as far as I could tell, these service IDs and their names are only used in the privileges list API and they seem there mostly for descriptive purposes. The list also rarely changes so if you need to list them in your application you could assign them your own names if they are missing. You can use the privilegeName field as a guide, for example.
If you still have questions about it you can try to file a post in their issue tracker at the product feedback link at the bottom of the page.
Related
I'm using FHIR R4 with Hapi FHIR API.
I want to know how marked the ServiceRequest resources with information about created user.
I've read the FHIR documentation and I've found the relevantHistory tag where I can put there a Provenance reference.
All good but the HAPI Fhir can't query that field/tag so I can't get all ServiceRequests created by me or another user.
I've also tried to use a customize extension named tracking, where I've put the tracking user info.
I don't want to use a requester tag because, it is filled with other guide line meaning supplied by customer
EDIT AFTER Mirjam Baltus
Hi,
interesting your point of view but, I've found another solution as follow, I want to discuss it with you (if you want).
I've added a SearchParameter resource attached on ServiceRequest to allow the search on relevantHistory field.
This is the JSON resource:
{
"resourceType": "SearchParameter",
"id": "6589",
"meta": {
"versionId": "7",
"lastUpdated": "2021-02-25T11:25:25.549+00:00",
"source": "#1btUOFbG0D3dMdwI"
},
"title": "Storia",
"status": "active",
"code": "relevantHistory",
"base": [
"ServiceRequest"
],
"type": "reference",
"expression": "ServiceRequest.relevantHistory",
"xpathUsage": "normal",
"target": [
"Provenance"
],
"modifier": [
"missing"
],
"chain": [
"reference"
]
}
So I've written a query on ServiceRequest filtered by relevantHistory field (linked to Provenance).
I've adopted this strategy because I need to know only the creator of ServiceRerquest, so in this way, I've factorized the information in Provenance resource where in the target field I've put the Practitioner / Organization who created the ServiceRequest and in the agent component I've replicated this information with ENTERER value in the enum AgentRole and AgentType.
In this way, I've collected one Provenance for more ServiceRequests, instead If I follow your way, I'll have for each ServiceRequest a dedicated Provenance.
You think I've followed a wrong way or it is a possible solution?
The relevantHistory is not the right field to use, since that will only list older Provenance resources that hold relevant information. The description specifically says it does not hold the Provenance resource associated with the current version of the ServiceRequest (see http://hl7.org/fhir/servicerequest-definitions.html#ServiceRequest.relevantHistory).
I think Provenance can still help you. You would not search on a field in ServiceRequest, but find ServiceRequests that have a Provenance where you/user are the actor:
GET [base]/ServiceRequest?_has:Provenance:target:actor=[user_reference]
Or approach it the other way around, by looking for Provenance resources from the user, and including ServiceRequests that are the target of the Provenance.
Added after edit of original post:
As I mention in my comment, I think the way you are trying to use the relevantHistory field and one Provenance for multiple ServiceRequests is not according to how that field and resource type are supposed to be used.
If you are able to create a custom search parameter, why not use an extension on the ServiceRequest to indicate who created it, and then make that extension searchable?
If you want more discussion about this, please ask on https://chat.fhir.org, where more people from the FHIR community will be able to chime in.
I have the following data structure that contains an array of sectionIds. They are stored in the order in which they were completed:
applicationProgress: ["sectionG", "sectionZ", "sectionA"]
I’d like to be able to do something like:
GET /application-progress - expected: sectionG, sectionZ, sectionA
GET /application-progress?filter[first]=true - expected: sectionG
GET /application-progress?filter[current]=true - expected: sectionA
GET /application-progress?filter[previous]=sectionZ - expected: sectionG
I appreciated the above URLs are incorrect, but I’m not sure how to name/structure them to get the expected data e.g. Are the resources here "sectionids"?
I'd like to adhere to the JSON:API specification.
UPDATE
I'm looking to adhere to JSON:API v1.0
In terms of resources I believe I have "Section" and "ProgressEntry". Each ProgressEntry will have a one-to-one relationship with a Section.
I'd like to be able to query within the collection e.g.
Get the first item in the collection:
GET /progress-entries?filter[first]
Returns:
{
"data": {
"type": "progress-entries",
"id": "progressL",
"attributes": {
"sectionId": "sectionG"
},
"relationships": {
"section": {
"links": {
"related": "http://example.com/sections/sectionG"
}
}
}
},
"included": [
{
"links": {
"self": "http://example.com/sections/sectionG"
},
"type": "sections",
"id": "sectionG",
"attributes": {
"id": "sectionG",
"title": "Some title"
}
}
]
}
Get the previous ProgressEntry given a relative ProgressEntry. So in the following example find a ProgressEntry whose sectionId attribute equals "sectionZ" and then get the previous entry (sectionG). I wasn't clear before that the filtering of this is based on the ProgressEntry's attributes:
GET /progress-entries?filter[attributes][sectionId]=sectionZ&filterAction=getPreviousEntry
Returns:
{
"data": {
"type": "progress-entries",
"id": "progressL",
"attributes": {
"sectionId": "sectionG"
},
"relationships": {
"section": {
"links": {
"related": "http://example.com/sections/sectionG"
}
}
}
},
"included": [
{
"links": {
"self": "http://example.com/sections/sectionG"
},
"type": "sections",
"id": "sectionG",
"attributes": {
"id": "sectionG",
"title": "Some title"
}
}
]
}
I started to comment on jelhan's reply though my answer was just to long for a reasonable comment on his objection, hence I include it here as it more or less provides a good introduction into the answer anyways.
A resource is identified by a unique identifier (URI). A URI is in general independent from any representation format else content-type negotiation would be useless. json-api is a media-type that defines the structure and semantics of representations exchanged for a specific resource. A media-type SHOULD NOT force any constraints on the URI structure of a resource as it is independent from it. One can't deduce the media-type to use based on a given URI even if the URI contains something like vnd.api+json as this might just be a Web page talking about json:api. A client may as well request application/hal+json instead of application/vnd.api+json on the same URI and receive the same state information just packaged in a different representation syntax, if the server supports both representation formats.
Profiles, as mentioned by jelhan, are just extension mechanisms to the actual media-type that allow a general media-type to specialize through adding further constraints, conventions or extensions. Such profiles use URIs similar to XML namespaces, and those URIs NEED NOT but SHOULD BE de-referencable to allow access to further documentation. There is no talk about the URI of the actual resource other than given by Web Linking that URIs may hint a client on the media-type to use, which I would not recommend as this requires a client to have certain knowledge about that hint.
As mentioned in my initial comments, URIs shouldn't convey semantics as link relations are there for!
Link-relations
By that, your outlined resource seems to be a collection of some further resources, sections by your domain language. While pagination as defined in json:api does not directly map here perfectly, unless you have so many sections that you want to split these into multiple pages, the same concept can be used using standardized link relations defined by IANA.
Here, at one point a server may provide you a link to the collection resource which may look like this:
{
"links": {
"self": "https://api.acme.org/section-queue",
"collection": "https://api.acme.org/app-progression",
...
},
...
}
Due to the collection link relation standardized by IANA you know that this resource may hold a collection of entries which upon invoking may return a json:api representation such as:
{
"links": {
"self": "https://api.acme.org/app-progression",
"first": "https://api.acme.org/app-progression/sectionG",
"last": "https://api/acme.org/app-progression/sectionA",
"current": "https://api.acme.org/app-progression",
"up": "https://api.acme.org/section-queue",
"https://api/acme.org/rel/section": "https://api.acme.org/app-progression/sectionG",
"https://api/acme.org/rel/section": "https://api.acme.org/app-progression/sectionZ",
"https://api/acme.org/rel/section": "https://api.acme.org/app-progression/sectionA",
...
},
...
}
where you have further links to go up or down the hierarchy or select the first or last section that finished. Note the last 3 sample URIs that leverages the extension relation types mechanism defined by RFC 5988 (Web Linking).
On drilling down the hierarchy further you might find links such as
{
"links": {
"self": "https://api.acme.org/app-progression/sectionZ",
"first": "https://api.acme.org/app-progression/sectionG",
"prev": "https://api.acme.org/app-progression/sectionG",
"next": "https://api.acme.org/app-progression/sectionA",
"last": "https://api.acme.org/app-progression/sectionA",
"current": "https://api.acme.org/app-progression/sectionA",
"up": "https://api.acme.org/app-progression",
...
},
...
}
This example should just showcase how a server is providing you with all the options a client may need to progress through its task. It will simply follow the links it is interested in. Based on the link relation names provided a client can make informed choices on whether the provided link is of interest or not. If it i.e. knows that a resource is a collection it might to traverse through all the elements and processes them one by one (or by multiple threads concurrently).
This approach is quite common on the Internet and allows the server to easily change its URI scheme over time as clients will only act upon the link relation name and only invoke the URI without attempting to deduce any logic from it. This technique is also easily usable for other media-types such as application/hal+json or the like and allows each of the respective resources to be cached and reused by default, which might take away load from your server, depending on the amount of queries it has to deal with.
Note that no word on the actual content of that section was yet said. It might be a complex summary of things typical to sections or it might just be a word. We could classify it and give it a name, as such even a simple word is a valid target for a resource. Further, as Jim Webber mentioned, your resources you expose via HTTP (REST) and your domain model are not identical and usually do not map one-to-one.
Filtering
json:api allows to group parameters together semantically by defining a customized x-www-form-urlencoded parsing. If content-type negotiation is used to agree on json:api as representation format, the likelihood of interoperability issues is rather low, though if such a representation is sent unsolicitedly parsing of such query parameters might fail.
It is important to mention that in a REST architecture clients should only use links provided by the server and not generate one on their own. A client usually is not interested in the URI but in the content of the URI, hence the server needs to know how to act upon the URI.
The outlined suggestions can be used but also URIs of the form
.../application-progress?filter=first
.../application-progress?filter=current
.../application-progress?filter=previous&on=sectionZ
can be used instead. This approach should in addition to that also work on almost all clients without the need to change their url-encoded parsing mechanism. In addition to that he management overhead to return URIs for other media-types generated may be minimized as well. Note that each of the URIs in the example above represent their own resource and a cache will store responses to such resources based on the URI used to retrieve such results. Queries like .../application-progress?filter=next&on=sectionG and .../application-progress?filter=previous&on=sectionA which retrieve basically the same representations are two distinctive resources which will be processed two times by your API as the response of the first query can't be reused as the cache key (URI) is different. According to Fielding caching is one of the few constraints REST has which has to be respected otherwise you are violating it.
How you design such URIs is completely up to you here. The important thing is, how you teach a client when to invoke such URIs and when it should not. Here, again, link-relations can and should be used.
Summary
In summary, which approach you prefer is up to you as well as which URI style you choose. Clients, especially in a REST environment, do not care about the structure of the URI. They operate on link-relations and use the URI just for invoking it to progress on with their task. As such, a server API should help a client by teaching it what it needs to know like in a text-based computer game in the 70/80's as mentioned by Jim Webber. It is helpful to think of the interaction model to design as affordances and state machine as explained by Asbjørn Ulsberg .
While you could apply filtering on grouped parameters provided by json:api such links may only be usable within the `json:api´ representation. If you copy & paste such a link to a browser or to some other channel, it might not be processable by that client. Therefore this would not be my first choice, TBH. Whether or not you design sections to be their own resource or just properties you want to retrieve is your choice here as well. We don't know really what sections are in your domain model, IMO it sounds like a valid resource though that may or may not have further properties.
In 2.6.3 Copying Resources and re-identification of DSTU1 there's a description of how clients may have to re-assign ids on resources pulled from a server. My question is what should be allowed when going in the opposite direction. I see no issue with accepting foreign absolute references when there's no re-interpretation needed (ie you accept the URI on POST/PUT and return the same URI on GET), but I'm wondering if they should be accepted if a re-identification is needed on the server side (ie you accept the URI on POST/PUT but assign a new id no the object such that subsequent GET's return a local relative URI).
Are there any guidelines in DSTU1 (or even DSTU2) related to this?
Example
The client POSTs the following:
{
"resourceType": "Patient",
"name": [{"text": "Irene"}],
"careProvider": [{"reference": "https://fhir.example.com/api/Organization/12345"}]
}
The client then does a GET and receives the following:
{
"resourceType": "Patient",
"id": "abc",
"name": [{"text": "Irene"}],
"careProvider": [{"reference": "Organization/987"}]
}
You can see that the server re-identified the Organization into a local reference.
There's no more material than what you already referenced. The material isn't meant to dictate the answers, only to suggest the kind of solutions that might be needed. Generally, then, it's not really possible to talk about what's allowed - except or one thing you mentioned: the server isn't allowed to accept a PUT and then not honor the PUT by moving the resource; it should reject the PUT and insist on a POST. But generally, the mix of clients, servers and middleware in an eco-system, I don't know that we can usefully make rules about what should and shouldn't happen
According to the Facebook documentation for the app insights (link) one can specify breakdowns parameters, namely app_event_parameter1, app_event_parameter2 etc. However, I failed to find any information how to do it. So, the question is where and how exactly to specify these parameters?
The names app_event_parameter1, ..., app_event_parameter10 are slightly misleading since the other breakdowns in the table are used exactly as listed.
For example, you would request the breakdowns client and auth_state like this:
{
"period": "monthly",
"breakdowns[0]": "client",
"breakdowns[1]": "auth_state"
}
However, if you've been logging a custom app event with a custom parameter "game_level" then you'd request that breakdown like this:
{
"period": "monthly",
"breakdowns[0]": "game_level",
}
You can supply up to 10 of your own app event parameter names as breakdowns.
I am trying to get realtime stock data from BSE and NSE using yahoo finance web-services. I was able to get some data using following URL
http://finance.yahoo.com/webservice/v1/symbols/COALINDIA.NS/quote?format=json
But it gives me very limited information.
{
"list": {
"meta": {
"type": "resource-list",
"start": 0,
"count": 1
},
"resources": [
{
"resource": {
"classname": "Quote",
"fields": {
"name": "COAL INDIA LTD",
"price": "367.649994",
"symbol": "COALINDIA.NS",
"ts": "1418895539",
"type": "equity",
"utctime": "2014-12-18T09:38:59+0000",
"volume": "2826975"
}
}
}
]
}
}
I need more information like yearly high, low, last traded price etc. and I couldn't find any documentation related to this from yahoo where it details how to get more information.
Is there documentation available related to these services? Or please suggest if there are any alternatives available.
I don't know where the definitive documentation might be but for your particular example try appending &view=detail to your URL.
http://finance.yahoo.com/webservice/v1/symbols/COALINDIA.NS/quote?format=json&view=detail
This will at least give you the year_high and year_low that you asked after.
Now, even though the following won't work for your COALINDIA.NS symbol (I suspect the exchange is not supported), it might be worth exploring the following two examples:
Example 1: As before, but for Apple and Yahoo symbols, with &view=detail appended:
http://finance.yahoo.com/webservice/v1/symbols/YHOO,AAPL/quote?format=json&view=detail
Example 2: And now using a completely different url, resulting in much more response data. One key caveat is this data is delayed by 15 minutes:
http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20yahoo.finance.quotes%20where%20symbol%20IN%20(%22YHOO%22,%22AAPL%22)&format=json&env=http://datatables.org/alltables.env
If you discover the major differences between those two options and what impact they might have then please do let us all know; I'd be interested in finding out more.
If you are fine with getting NSE qoutes, you can use this package for the purpose, it is extremely easy to setup.
http://nsetools.readthedocs.org/en/latest/index.html
Since it uses NSE website/services as data source, the quotes will not be delayed (max few seconds).
Beware that these data are both delayed and inconsistent. You are not getting anything even remotely close to tick or real-time data.
From example 2, refresh a few times, and inspect the "LastTradeWithTime" key-value pair. I sometimes get different quotes from different times of day, for no apparent reason. They are sometimes delayed up to three hours.
You get what you pay for; in other words, this is not a free lunch.
For those who are curious about the different options available in the Yahoo Finance URLs, I think these links might help. If it's not what you're looking for, sorry.
http://internetbandaid.com/2009/03/31/yahoo-stocks-api/
https://ilmusaham.wordpress.com/tag/stock-yahoo-data/
Note: the wordpress site contains information that was taken from a site called gummy-stuff.org which is listed in full at the bottom of the above site (I can only list 2 urls in this post so I had to do the round-about way). Oddly, I found this site on my own yesterday. Funny how stuff comes back around. If you visit this site you'll just see a statement from Yahoo that the info he had originally listed (you're looking at some of this site on the above wordpress site) was never intended to be for public consumption and is a violation of Yahoo's terms and conditions agreement as it can apparently be used for hacking purposes. I was curious to see what was on the original post so I searched for it on the WayBack Machine. BTW, the links to the spread sheets are still active in the archive.
Cheers. Thom