When opening an API specification in Microsoft Azure API management we are giving some name and the swagger specification file also has some name as title. The name which we have given coming as API id and the title available in the Swagger.json is coming as API display name. So what is the difference between API id and API name in Azure API management?
It's common to all Azure resources to have name and id. Resource id is full "resource path" that goes like "/subscriptions/.../resourceGroups/.../providers/...". Last segment of that path is resource name.
Name is fixed field of the Contact Object in OpenAPI.
Name reflects the identifying name of the contact person/organization.
There's no id field in Contact object or any other openapi description fields, but openapi file may have user made id parameter.
Please, see this example:
parameters:
- name: id
in: path
description: ID of pet to use
required: true
schema:
type: array
style: simple
items:
type: string
Take a look at operationId. operationId is an optional unique string used to identify an operation. If provided, these IDs must be unique among all operations described in your API.
Related
I'm using Postman to query the Dynamics 365 Web API to fetch Account records. I'm trying to use expand to fetch some properties from the related SystemUser record via the ownerid field.
Here is what I think the query should look like:
https://myorg.api.crm4.dynamics.com/api/data/v9.0/accounts?$select=name&$expand=ownerid($select=fullname)
When I submit this query I get the error:
Could not find a property named 'fullname' on type 'Microsoft.Dynamics.CRM.principal
I know that the fullname property definitely exists on a SystemUser.
If I remove the ($select=fullname) part of the query I get the following JSON result but I was expect lots of properties for the expanded owner.
{
"#odata.context": "https://myorg.api.crm4.dynamics.com/api/data/v9.0/$metadata#accounts(name,ownerid)",
"value": [
{
"#odata.etag": "W/\"1564360\"",
"name": "My Account",
"accountid": "82b287d6-0dc7-e811-a95e-000d3ab1ab19",
"ownerid": {
"ownerid": "5f8872b1-0189-e811-a975-000d3ab38ab1"
}
}
]
}
If I change the expand to use primarycontactid then this works and I can fetch fields from a Contact record.
I've checked the documentation and I'm no further forward.
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/query-data-web-api
How do I use expand to fetch properties from a SystemUser record via the ownerid property of Accounts?
It looks like the issue is due to the Owner field being able to point at either a SystemUser or Team record.
If I expand with owninguser then I can fetch the correct properties from the related Systemuser.
/api/data/v9.2/new_customs?$select=createdon,_ownerid_value&$expand=owninguser($select=fullname)&$filter=(owninguser/systemuserid%20ne%20null)&$top=50
Microsoft Graph API's User entity has field "userType". According to documentation there is no any information about this. There is one line: "A string value that can be used to classify user types in your directory, such as “Member” and “Guest”. Supports $filter.". So there is no any limitations :-)
Can be "userType" null? I can't PATCH existing user manually via graph api - graph api return an error. But on production we have some users, which have "userType": null
Which values are valid for "userType"? Can you provide it in documentation or here please?
According to your questions, I suppose you want to know the valid value of the field userType. we can refer to the content of User Entity.
For your first question, we can set the field userType to null, not " " or "null". When we create a user, the default value of this field will be Member if we didn't set it.
We can patch existing user. Based on my test, we can modify it like this:
PATCH https://graph.microsoft.com/v1.0/users/{userid}
{
"displayName": "XXX",
"givenName": "XXXX",
"jobTitle": "Marketing Director",
"userType": "Guest"
}
This will modify the user'userType from Member to Guest.
For your second question, according to the content of User Entity and the article of Azure AD User, the valid value for userType is "Member" and "Guest". Based on my test, it is sure that only these two values can be used.
I tried MS Graph API with following GET request: https://graph.microsoft.com/v1.0/users/?$select=id,mySite
However, it reports error Value cannot be null.\r\nParameter name: source.
It works if I remove mySite or change it with another user property such as userPrincipalName.
This is a known limitation of the users endpoint (i.e. the collection of users). From the documentation:
Note: Listing users returns a default set of properties only
(businessPhones, displayName, givenName, id, jobTitle, mail,
mobilePhone, officeLocation, preferredLanguage, surname,
userPrincipalName). Use $select to get the other properties and
relationships for the user object. However, only the following
properties can be selected for individual users, and not for collections of users: aboutMe, birthday, hireDate, interests, mySite, pastProjects, preferredName, responsibilities, schools, skills, mailboxSettings
For easier reading, the list of unsupported properties are:
aboutMe
birthday
hireDate
interests
mySite
pastProjects
preferredName
responsibilities
schools
skills
mailboxSettings
Wondering if anyone knows of any way to extend or configure Breeze so that the server returns additional info in the entity metadata? I'd like to use this additional data to assist with validation.
Assume I have an entity model like so with some Data Annotations applied:
public class Person {
[RegularExpression(#"^$|^http\://[a-zA-Z0-9\-\.]+\.[a-zA-Z]{2,3}(/\S*)?",
ErrorMessage="The Website address does not appear to be valid.")]
public string Website { get; set; }
[Required(ErrorMessage="The Name field is required."),
MaxLength(150, ErrorMessage = "The Name field cannot exceed 150 characters."),
MinLength(5, ErrorMessage = "The Name field must be at least 5 characters.")]
public string Name { get; set; }
//...
}
Right now, Breeze only hooks up a MaxLength and Required Validator based on the metadata it receives since this is all it supports out of the box. If Breeze could include in the metadata the info described in the Data Annotation Attributes on the server entity, I'm thinking it would then be possible for Breeze to automatically add additional stock validators to the client EntityType (e.g. for RegEx, Range, MinLength, etc... ). This would cover the majority of basic validation use cases. Or, it could also allow developers to inspect the metadata and pull out useful info like the regEx string which we could use to hook up our own custom RegEx validator.
Also, is there any way to have Breeze include the value of the ErrorMessage validation attribute property in the metadata and then have the breeze client use that instead of the default required and maxLength messageTemplates? This would mean you would only have to define the error message in one place on the server and wouldn't have to customize it for each entity.
I'm trying to avoid having to create and register a bunch of custom validators on the client for what seems like basic validations that could be handled by Breeze automatically.
Thanks,
Richard
It's a great question.
We haven't yet done a good job of documenting how the server serializes metadata but this should be coming "real soon now". However, if you take a look at the json coming over the wire you'll notice that validators are serialized simply by name. This name is then looked up among the registered validators ( or validator factories) on the client and then added to the client side metadata. So the idea would be to register you validator "implementation" on the client with a unique name, and then have the server reference this name when sending metadata down from the server.
Hopefully this will be clearer in a week or so once we have documented how to create your own server side metadata to send down to the client.
Hmmm, one year has passed. Any news on this topic? I fully agree with RWHepburn that defining all validation rules on the server-side and have it available in breeze on the client side would be a perfect thing. This is what data annotations in EF are for - making it easier!
I have an entity OrderItem that has OrderId and ProductId integer fields and these two fields form the identity key/primary key for this table.
I would like to use OData/Web API to expose such entities through a service and to be able to select OrderItem instances by they composite ID.
What should be the format of the URL?
Are there any best practices for handling such scenarios?
Composite keys in the URL use syntax like this:
~/OrderItems(OrderId=1234,ProductId=1234)
The "grammar" is defined in the OData ABNF Construction Rules (see the definition for "compoundKey")
An example usage can be found in OASIS' OData Version 4.0. Part 2: URL Conventions Plus Errata 03
Note that the "composite key" (aka "complex key predicate") has been around since OData 1.0.
First, you have to make sure that you explicitly mention that it has a composite key, in configuration file
builder.EntityType<OrderItem>().HasKey(t => new { t.OrderId, t.ProductId});
Then, the action should have the following header
public SingleResult<OrderItem> Get([FromODataUri] string keyOrderId, [FromODataUri] string keyProductId)
Please note the prefix(key) used for both parameters!
This is OData V4. Please also refer to https://odata.github.io/WebApi/13-06-KeyValueBinding/