The descriptions of the property modifiedProperty do not contain a list of (or a link to) its possible values, which makes it difficult to utilize APIs that return this resource type.
Document Details
Content: modifiedProperty resource type - Microsoft Graph v1.0
Content Source: api-reference/v1.0/resources/modifiedproperty.md
Product: microsoft-identity-platform
Technology: microsoft-graph
Link : https://github.com/microsoftgraph/microsoft-graph-docs/blob/master/api-reference/v1.0/resources/modifiedproperty.md
It would be helpful if the list of possible values could be provided.
I highly doubt you're going to be able to find such a list. The values of the modifiedProperty property are going to vary based on which type of Azure resource you're looking at and which property on that resource was modified. The only thing you can be certain of is that the modifiedProperty will be empty or it will contain a property name, the old value, and the new value, according to the documentation you linked.
If you are trying to code for a particular type of Azure resource or a particular type of property, you should look into the documentation for that resource or property instead of the documentation for getting that information.
Related
The documentation mentions that extended properties are a finite resource in a user's mailbox, and exceeding this limit will result in unexpected errors when trying to create new properties.
It is not mentioned explicitly anywhere that I could if item customProperties, as written to through the Office.js client, has the same limitation. Does it?
We plan to optionally write a small amount of data to item customProperties if the user modifies inputs exposed in our Add-in Taskpane in the Outlook client. These properties will later be read by a server consuming changed events through the events delta API.
Will we eventually run into issues with this approach if we don't implement some sort of "garbage collection" of no longer used customProperties?
Item custom Properties are extended properties https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcext/4cf1da5e-c68e-433e-a97e-c45625483481?redirectedfrom=MSDN
So you have one extended property and then the value is a Json Key pair so one Extended property provides multiple custom properties (up to the limitation of the size of the Extended property)
Even if you don't want to use Item Custom properties its a good idea to follow the same approach eg create one extended property for your app and then store what ever combination of property values you need as a JSON structure in the value on the property. Its not a good idea to have your application creating random/multiple custom properties as you will easily exhaust them/create a mess and there is no advantage in doing it that way.
I'm attempting to get all OrgUnits using Valence that are the "Department" type. When I do the call to /d2l/api/lp/1.4/orgstructure/?orgunittype=Department, I get a paged result set containing all the OrgUnits
The docs are a little unclear. They specify that
You can use the orgUnitType, orgUnitCode, and orgUnitName query parameters as filters to further narrow the list of org units this action retrieves.
and also
orgUnitType (string) – Optional. Filter to org units of this type.
However, "string" is a bit ambiguous considering OrgUnitType is a composite type with both a code and a name as a string. Both my Code and my Name for this type is "Department yet it still gives me everything.
You should provide an org unit type identified by a valid orgUnitTypeId (for course offerings, this will be 3.
For custom org unit types, like "Department", the value will most likely vary LMS to LMS:
You can use the call to retrieve the list of all known org unit types to determine the type corresponding to "Department" for your LMS.
Or, because "Department" is one of the very common custom org unity types, you can use the specific get department-org-unit-type call to find out what the ID is for that type on your LMS (there's also a specific call like this to get the type ID for "semester" org units).
for our scopes we need to use unique ID generated by us for the answers submitted by users. This is possible by adding "?c=" at the end of the survey link followed by the ID number.
Example Format: http://www.surveymonkey.com/s/XXXXX?c=00001
The terrific problem is that the custom value is not returned anyway via API. It is not added as a property of the Answer object neither its value replaces somehow the respondant_id property.
We see that you are able to expose that data from your internal endpoints that you use for your proprietary web interface but how to get this data from he outside via API?
Thanks
When you call 'get_respondent_list', ensure you pass through 'custom_id' in the list of strings in the 'fields' parameter. This will then be returned in the output with the custom value you entered.
I understand that in MVC pattern and in REST services it is common to use URIs like /items/{id} but what is bad thing about using query parameters in the URI?
GET /items/{id} vs GET /items?id={id}
Further, lets say an entity has 'referenceId' field that points to some related (say parent) entity, and I need to create REST service to get all items for parent entity, which way is better:
GET(POST) /items/parent/{parentId}
or
GET(POST) /items?parent={parentId}
Will be grateful for insights that would help to resolve my subjective issues on constructing URLs for REST services.
I would use the following schemes.
/items/id
This uniquely addresses a resource of items with id id. We are not using parameters as a parameter to uniquely address this resource (as is the case with the other option). Just as
miguelcobain suggests.
/parent/id/items
Here id is an id to uniquely address a resource of parent and from those we collect/retrieve the items it references. From what you have said in the question it seems that parent references multiple items, like a container or collection.
The convention I use for this is to narrow down the scope going from left to right. Therefore in case items could be active or inactive. Thusly items have a property or attribute to be active or inactive. Narrowing down on this I get the following scheme:
/items/active
/parent/id/active
For your first question:
/items/{id} should retrieve a single resource with the specified id or 404 if it doesn't exist.
/items/?id={id} should retrieve an array (even if only one in the array) because you are querying the collection.
For your second question:
I agree with #miguelcobain's assessment - if the item is a specific resource/entity, just use the proper resource path to retrieve it.
To make this easier on the consumer, create a link header with rel="parent" and/or include the uri in the child resource. For an example of link headers, see GitHub's pagination api.
Of course, REST principles don't care about aesthetic details on URLs. It just imposes that every resource should be uniquely addressable.
Furthermore, using the query parameters to uniquely address something "kind of" violates the semantics of a "parameter", doesn't it? A parameter should be something optional, something additional and parameterized. Something like a detailed search on a collection of items, for example.
What you wrote may make sense in some cases. It depends.
In your example, is the item really a resource? If not, you could just do GET(POST) /parents/{parentId}.
If parent is, say, a boolean, and you want to search the items that have parent equals to true, then using the parameters makes sense. But since you're explicitly saying that you want a parent with a specific id, I assume that parent is a resource itself and I would uniquely address that resource using your option 1.
I hope I made myself clear.
It seems to me there are no rules to follow.
items/{id} - this convention is suitable for GET item by given id. If user doesn't provide id then it returns 404 status code.
items/id={id}&name={name} - this type of convention is suitable for search multiple items by given criteria. If no items are found, it is not a 404 situation, you simply say "I successfully found nothing matching your search criteria"
Is it possible to query an OData collection filtering by the updated metadata field? The case for that would be to get a list of updates since the last check.
I've tried http://odata.netflix.com/v1/Catalog/People?$filter=updated%20eq%202011-05-15T21:45:31Z, but it gives me "No property 'updated' exists in type 'Netflix.Catalog.Person' at position 0". Is there another way I can do this or reference the updated property in a filter statement?
The updated element in the ATOM feed/entry representation may or may not contain actual data. Some services actually do store the real updated timestamp there, but some don't. Since the element is required to be present in all entries by the ATOM format, services which don't have the data to use there usually put some arbitrary timestamp as the value (by default WCF Data Services uses DateTime.Now for the updated field, which is what netflix service does as well).
The $filter can only reference real properties on a given entity. So if the service does have a property which contains the data backing the updated element you would need to find out the name of such property (in the $metadata for example) and then use that. If the service does not have a property like that (for example the netflix service doesn't), then there's no way to filter based on last updated timestamp, as there's no such thing in the underlying data store (the updated element is effectively a fake).
Also note that if you ask for JSON payload the updated element doesn't exist there and so only the real properties are present. Any query operators in the URL work only on the real properties.