If for example an Asset contains Relationships property for owner then when using GetSingle API (from a client App) we get back something like: "owner":"resource:somenamespace.owner#owner01". (i.e. related participant is owner with ownerId = owner01).
What is actually being returned for the relationship property?
Is there anyway we can actually get back all the properties of the related instance (owner with ownerId = owner01) in the same call? I have tried adding parameter to the Rest call such as below but no joy.?resolve=true&include=true.
If I can't get related instance properties in same Rest call then how do I extract out the related Id (e.g. owner01 in above example) from the returned "owner":"resource:somenamespace.owner#owner01"I can then do a separate GetSingle call to the owner Rest end point using the extracted ownerId?I have tried searching the web for docs on such Rest API parameters/processing of results but no joy.Many thanks.Lalji
1) What's returned is a URI resource ID for the related object (ie owner)
2) Yes. Use Loopback filters to resolve. For example ('GET' call - eg. using httpClient or axios etc eg - two examples:
GET 'http://localhost:3000/api/CommodityAsset?filter={"where":{"assetId":"A01"},"include":"resolve"}' // narrow filter - for one asset
GET 'http://localhost:3000/api/CommodityAsset?filter={"where":{"ownerId":"resource:org.acme.biznet.owner%23T01"},"include":"resolve"}' // broader, assets owned by a particular owner, could be many
where %23 is '#' the encoded character used in Composer language relationship notation.
Related
So I have done a lot of research and could not find a proper answer. This might be a bit long post so sorry for that. I am making a backend API using golang. I am using gingonic for routing and api stuffs.
There are 2 part of the service. Application and user. When lets say createAccount endpoint is called from the other micro service, it need to pass the user information and application token in body. Each application is like micro service that is registered to this micro service that I am building and have a unique token. If the token they pass matches then I will get the id of that row and use that to create an entry in user table which will have the id associate with it.
Now for every API call to this micro service, it is important that they are sending the valid token and that row id is needed to do all sort of functionality like login user, edit user info and so on as the each user is connected with that app id by foreign key. Currently, I wrote a middleware and when any api call is made I get row id and save it to a global variable and then when necessary I am using it in any part of the codebase.
Lets say if 5 multiple API call is made, will that global variable information will be persisted or for each call its brand new value? If it is persisted then what can I do to achieve the brand new of Global variable for every API call or if there are better approach can you please recommend it?
A global variable is not the answer here. It will be overwritten by each request as you suspected. Instead, the typical way to handle this situation is to have a context object that is created within the scope of the HTTP Request and passed to each method that requires knowledge of that context.
One basic rule is to AVOID using the global variables, it is bad practices, you cannot manage the state and you are limited for testing and concurrency using.
In my mind come two basic solutions:
Use context for this. In your handler, add the value in context and propagate this context by all your service calls. It is also useful for tracing if you are working with microservices, then you also should take a look for this. And in the place where you need the value from your global variable, do simple call: ctx.Value(YOUR_KEY) Take a look at the end of the page, you shouldn't use string as the key to context values.
You can wrap your data in the struct with this variable value. For example:
type CreateReq struct {
Token string // value from global variable
User user
}
and use this Token in your services.
Specifically, can SCIM be used to add Users to pre-existing (non SCIM-created) groups? We need to provision users via SCIM, but then add them to Groups created manually in the site (a .Net application).
As I understand it, it can't be done like this. Group Update requests (i.e. PATCH requests) seem to require the "id" attribute as the unique identifier for the group, and this "id" seems to be only generated in SCIM Create Requests. So if a Resource (Group / User) wasn't originally created via SCIM, SCIM can't update/replace/delete it. Is that correct?
e.g. PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
I thought about a workaround convention, such as using "user:1234" and "group:1234" as the "id" attribute format (i.e. [resource type]:[internal type-specific ID]), and then any User or Group can be specified by "id", even if it wasn't created via SCIM. But that seems pretty hacky.
Is there a better way of doing this? Many thanks for any help, very new to SCIM!
Yes, SCIM can be used to manage "brownfield" scenarios where existing non-SCIM created objects exist.
Typically the logic flow that happens for a user object is:
GET on /users with a filter (as defined in RFC7644 3.4.2.2) using an attribute that is uniqueness constrained (such as userName, email).
If no user found matching that criteria, create a new user with POST to /users
If a user was found, it should bereturned with an id value even if it was not created via SCIM
The general logic of "Search using a friendly identifier -> create if not found/cache the id value and associated it with existing user in the other directory" is pretty simple and can be successfully used with other object types (ie: groups) as well.
I am pondering about schema design with regard to explicit vs implicit relation when to...
for example:
in an imaginary schema with 2 custom types author and post, each with several properties, A post type can reference an author in 1 of 2 ways:
explicit: having an Autor type property
implicit: having a scalar value that indirectly points to the author
when designing a shema. what should be my compass in this kind of desicion making?
thanks in advance
There's absolutely no value to the client in only returning the ID of a related resource when you could just expose a field that would return the entire resource. Exposing only the ID will mean the client will have to make subsequent requests to your service to fetch the related resources, instead of being able to fetch the entire data graph in one request.
In the context of other services, like a REST API, it might make sense to only return the ID or URL of a related resource. This is because in those cases, the payload is of a fixed size, so returning every related resource by default can quickly and unnecessarily bloat a response. In GraphQL, however, request payloads are client-driven so this is not a concern -- the client will always get exactly what it asks for. If the client needs only the author's ID, they may still fetch just that field through the author field -- while allowing a more complete Author object to be fetched in other requests or by other clients.
I would like to know the usage scenario of POST vs PUT in a WebAPI . I know the basic concepts that POST is for creating resource and PUT is for updating resource but not able to fully understand why we need a PUT over a POST.
I have 2 WebAPI methods which creates/updates data to my SQL store
1. CreateUser(UserDto)
2. UpdateUser(UserDto)
UserDto contains userId, username and email.
I can use POST for both CreateUser and UpdateUser methods which creates and updates user to my store.
Then what is the real advantage of using POST for CreateUser and PUT for updateuser? Is it just a standard/convention?
Thank you
POST always creates something new. PUT updates a existing thing. It is a convention.
You should have:
POST /users : to create a new user. The payload should not include the ID
PUT /user/(id) : to replace a user DTO with the data in the payload. Again, the payload should not contain an user id
PATCH /user/(id): to update specific members of the user, but the id.
It is a design convention, like software design patterns, to make it easy to communicate and understand by whoever has to consume the API.
POST is usually used to add a new resource into collection of resources.
Like this: POST /users.
This operation is NOT idempotent and it will have a side effect at each call.
While PUT is usually used with a replace semantic and you know the exact resource which you want to replace.
Like this: PUT /users/1.
This operation is idempotent and it will not have any side effects on subsequent calls.
I have a SPA (single page application) so it uses AJAX extensively for getting and saving data to and from the server. In one case I allow the admin to view/add/edit/delete users. Some current urls for this area looked something like:
(GET) /users?userId=1 // get user with id of 1
(POST) /users?userId=1&firstName=Jim // update the first name of the user with id 1
(POST) /users?firstName=Bob // create a new use with the first name Bob
(POST) /users?userId=1&delete=true // delete user with id of 1
Having spent some time working on a RESTful API in a related project, I'm wondering if it's preferred to use HTTP types (GET, POST, PUT, DELETE) in a web app as well. Also, is it better to use a path parameter for user id instead of a query parameter? So are these urls (rewrite of the ones above) a better option in the long run:
(GET) /users/1 // get user with id of 1
(PUT) /users/1?firstName=Jim // update the first name of the user with id 1
(POST) /users?firstName=Bob // create a new use with the first name Bob
(DELETE) /users/1 // delete user with id of 1
In theory yes you should. You should be as RESTful as possible which means using HTTP semantics to their fullest. However the reality is a bit more murky, several older browsers, I don't need to name names, don't support anything but GET and POST. So the current recommendation until those browsers go out of support, or until you drop support for those browsers, is to have backup methods that do the same thing but on POST, usually with an extra parameter or segment in the url.