when we create projects via API the newly created project is immediately returned in both the webApp and in the API.
But a tag created using API "https://app.asana.com/api/1.0/tags" is often returned only after two or three GET requests. Also in the webApp it needs a refresh, online application sync does not update new tags like Projects.
This late returns really affects the user interaction. I follow the same workflow thats used for creating and adding project, but tags feels a bit laggy. Am I missing anything?
The answer is that tags which aren't associated with any tasks are - unfortunately - hidden in the app, and consequently also in the API. As you discovered, you can get the ID back from the POST to create and then associate it with a task from there (since there's little purpose in creating a tag if you're not associating it with something that shouldn't typically be a problem, but it is clunky). We are looking at changing our data model for tags to be a bit more intuitive in future, but that's still a ways off, so this is the reality for the foreseeable future.
the newly created tag is missed in the GET /tags API from time to time. But the http response returned after creation of the new tag by POST /tags, will contain the id, name and other properties of the newly created tag. So we can add the new tag from this response.
POST-> https://app.asana.com/api/1.0/tags \
-u "name=fluffy" \
-u "workspace=14916"
# Response
HTTP/1.1 201
{
"data": {
"id": 1771,
"name": "fluffy",
...
}
}
Related
In my example architecture; I have an IN-Mobius and a ADN-AE-Thyme (nCube Thyme).
First of all; i created a AE which is called "ae_test_02", i can GET this resource via Postman.
After this step; i run ADN-AE-Thyme, thyme.js, and it created a container which is called "thyme_01", and also i can GET this resource via Postman.
Also in that step, thyme.js add containerInstances into the "thyme_01" container. Then, i can get that latest containerInstance with "/la" parameter via Postman
In this point, the problem has began. I create a group resource, while creating i tried couple solutions, always fail. I tried in "mid" attribute;
{ "m2m:grp": {
"rn": "grp_test_100520_08",
"mt": 3,
"mid": ["3-20200505012920476/la",
"Mobius/3-20200505012920476/la",
"Mobius/thyme_01/la",
"Mobius/ae_test_02/3-20200505012920476/la",
"Mobius/ae_test_02/thyme_01/la",
"ae_test_02/thyme_01/la",
"ae_test_02/3-20200505012920476/la"],
"mnm": 10
}
The problem is that, i tried these mid paths one by one, but never works. When i try to get latest containerInstances via Postman, i use this URL and the results is "resource does not exist (get_target_url)"
The containers and contentInstances in the IN-Mobius, and i requested to the IN-Mobius. By using these informations how should i implement group "mid" attribute; for the get containerInstances via group resources ?
First Edit.
Hi Andreas.
For the first issue, i can get resource correctly. In this point my aim is GET containerInstance in the container, which is a member (mid) in that .
Second; now I understand, there is not existing resource in resource, okay. As you mentined, i want to pass a request to all member (containers) of a resource. For this purpose, i will use https://localhost:7579/Mobius/grp_test_100520_08/fopt, but it gives an error "ERR_INVALID_ARG_TYPE". I know that, at least one mid structure is correct, but which one is the correct ?
For the smaller issue, i already know that resouce multiple times in the mid attribute, because i did not know which one is the correct adressing scheme ?
Also, while creating a resource, the resource should be in the ae resource (/Mobius/ae_test_02/grp_name) or in the Mobius (/Mobius/grp_name)
resources can be in directly in IN-Mobius or should in MN-Rosemary? Is fanOutPoint only using by external resource like MN or even IN, fopt using ?
Second Edit.
The "thyme" comes from nCube Thyme (https://github.com/IoTKETI/nCube-Thyme-Nodejs), it creates a container and then randomly create ContainerInstances.
The resource tree looks like;
Mobius >> ae_test_02 (AE resource) >> thyme_01 (Container It created from nCube Thyme https://github.com/IoTKETI/nCube-Thyme-Nodejs) >> ContainerInstances
I have also a resource in >> Mobius >> grp_test_100520_08 (GROUP resource which is uses)
I tried;
{ "m2m:grp": {
"mid": ["Mobius/ae_test_02/thyme_01"],
"mnm": 5
}
}
In this request, fopt.js gives an error "callback is not a function".
{ "m2m:grp": {
"mid": ["ae_test_02/thyme_01"],
"mnm": 5
}
}
In this request, fopt.js gives same "callback is not a function", but in different line.
I guess my fopt.js file is old, then i checked mobius github page and get that file, however it not solve this.
Also my resource look like this;
Also my fopt.js file is same as this;
https://github.com/IoTKETI/Mobius/blob/master/mobius/fopt.js
UPDATE 3.
The "cnm" attribute problem is this; while creating a resouce, CSE will automaticly assign "cnm" attribute according to member size. However, CSE will not this process in UPDATE (PUT) request. From this point, i will create resources, not UPDATE them.
As you mentioned, i send requests to the group's resource, but it gives the "callback is not a function" error. To solve this problem, i downloaded and installed the whole distribution. (https://github.com/IoTKETI/Mobius) After that, i will do same processes again for understand the fopt.js file behaviour. The result wasn't changed, it gives the same error.
I planning to explain whole situation and create an issue, in Mobius github page. I hope they will response soon.
I think there are two issues with your example.
The first issue is with the request to the <Group>. You need to distinguish between requests to the <Group> resource itself and requests to the members of the <Grou>.
There is no child resource <la> of the <Group> resource itself. This is why you receive an error message. If you want to pass a request to all members of a <Group> resource then you need to target the virtual child resource <fopt>. In your case the request should target URI https://localhost:7579/Mobius/grp_text_100520/fopt. Since you already have the <la> resources as members you won't need to add the /la part to the request. However, I would recommend to only add the <Container> resources to the group and use the target URI https://localhost:7579/Mobius/grp_text_100520/fopt/la to retrieve the latest <ContentInstances> of each container.
The second (smaller) issue is that from what I can get from your example code that you add the same resource multiple times to the group, but only with different addressing schemes. Please be aware that the CSE must removes duplicate resources when creating or updating the mid attribute.
Edit after question update
It is not very clear what your resource tree looks like. So, perhaps you should start with only one resource references and continue from there. Valid ID's in the mid attribute are either structured (basically the path of the rn attributes) or unstructured ID's (the ri's). The CSE should filter the incorrect ID, so you should get the correct set of ID's in the result body of the CREATE request.
btw, where does "thyme" come from? This is only in a label, which does not form an ID.
Regarding the <fanOutPoint> resource: Normally all request would be targeted to the <Group> resource, but requests to the virtual <fanOuPoint> resource are forwarded to al the members of the group. If a resource referenced in mid is accessible then the request is forwarded and the result is collected and is part of the result body of the original request.
You also need to be careful and regard the resource types: only send valid requests to the group's members.
Update 2
From the IDs in the mid attribute of the <Group> resource it looks like that the CSE validated the targets (though the cnm (current number of members) is obviously wrong, which seems to be an error of the CSE).
So, you should be able to send requests to the group's <fopt> resource as discussed above.
For the CSE runtime error you should perhaps contact the Mobius developers. But my guess is that you perhaps should download and install the whole distribution, not only a single file.
for anyone in the future; who is dealing with this problem.
The problem is simply is that; in the app.js there is 4 function call (fopt.check). While calling the function in the app.js file, there are 5 parameter exists, on the other hand, while getting these arguments in the function it takes only 4 arguments. For this reason, body_obj always becomes "undefined" then it will never reach the "Container" or "ContainerInstance" source. Lately, KETI was sent a new commit to the Mobius Github page (https://github.com/IoTKETI/Mobius/commit/950182b725d5ffc0552119c5c705062958db285f) to solve this problem. It solves this problem unless you are using use_secure == 'disable'. If you try to use use_secure == 'enable' you should add an if statement to check use_secure and add import HTTPS module.
Also, while creating resource, defining the "mid" attribute is not very clear. Just for now, if you want to reach (latest) source; you should add "/la" for all members of the group. This is recommended by KETI on Github page issue 5.
(https://github.com/IoTKETI/Mobius/issues/5#issuecomment-625076540)
And lastly, thank you Andreas Kraft; your help was very useful.
I have deployed my business network using composer-rest-server and am able to call the API using postman.
For now I have hard coded ID's for participants/assets, so I cannot make another POST call as objects with the ID already exist.
Where can I delete the existing participants/assets? On composer playground there was a delete button on the testing page that provided this functionality.
If you are using POSTMAN, you can use the DELETE request to remove your test data.
Using the Trade sample from the Composer tutorials, you would use the following curl command to remove the Commodity COAL:
curl -X DELETE --header 'Accept: application/json' 'http://localhost:3000/api/Commodity/COAL'
If you want to remove all the data in you Business Network, you could investigate the composer network reset command. (described here in the Composer docs.)
using javascript composer-client you can do the following:
const { BusinessNetworkConnection } = require('composer-client');
const participantRegistry = await BusinessNetworkConnection.getParticipantRegistry(registry name space, type);
await participantRegistry.remove(registry name space#participantId);
const assetRegistry = await BusinessNetworkConnection.getAssetRegistry(registry name space);
await assetRegistry.remove(registry name space#asset id);
or even you can perform more
await assetRegistry.removeAll(registry name space);
however before deleting participant from registry you should revoke the bounded identity to it by doing the following:
const IdentityRevoke = require('composer-cli').Identity.Revoke;
let options = {
card: 'admin#tutorial-network',
identityId: 'f1c5b9fe136d7f2d31b927e0dcb745499aa039b201f83fe34e243f36e1984862'
};
IdentityRevoke.handler(options);
you can find more information in the documentation about revoking identity in the following link
Since you have deployed the API, use its Swagger interface to look at what you can do. It is a RESTful api which means each endpoint accepts the HTTP verbs that make sense for it.
Each asset and participant endpoint, for example, accepts DELETE requests where all you have to do is pass the ID of the entity you want to delete.
You can issue POST requests to create new data and PUT requests to update the data.
One thing to be aware of is that each request will create a new block on the ledger. DELETE doesn't mean the previous block disappears, it simply means it's in a deleted state and your block count keeps increasing for each transaction you issue.
If you want to run tests and make sure your assets get created properly then you can start using the feature files, there is a sample feature to get you started. It uses a specific composer cucumber package, you can see that if you look inside the package.json. This would be the preferred method to run tests, as this isn't a normal environment where you create test data and then delete it, you have to be careful as your block count will keep increasing.
I have created two users, and if i create a bucket for one user and an object inside that bucket i can share it using the HTTP api at the moment.. see here
https://simperium.com/docs/reference/http/#objectshare
However, even when i sent through "write_access" = true and get a 200 as a result, it doesnt seem to let me write to it.
Its only if i enable sharing back the other way that it allows data to sync both ways, am i doing something wrong?
Has collaboration got any further yet? i can see there is a long but no docs as yet? anyone know?
After some more trial & error, I found the solution:
to edit the shared object, the target user (ie the user that the object was shared with) needs to use an objectId that is equal to: <original_user_simperiumId>/<original_objectId> to edit the object.
If you just use <original_objectId> it won't work.
So the full command for editing a shared object, using curl:
curl -H 'X-Simperium-Token: {auth_token_of_target_user}' https://api.simperium.com/1/{appID}/{entity}/i/{original_user_simperiumId>/{original_objectId} -d '{"data_key" : "new_data_value"}'
i want to create an issue in JIRA by using the REST API provided by JIRA.
i am able to create a simple issue,
using this :
http://localhost:8080/rest/api/latest/issue
and data as follows:
{"fields":{"project":{"key": "TES"},"summary":"user name not showing validation message","description":"Hi validation is missing from user name","issuetype": {"name": "Bug"},"reporter":{"name":"BruceWayne"} }}
this is running fine.
now i want to add 3 custom fields while creating an issue. The custom fields are Authorname,
AuthorTag,AuthorID. how can i do this in rest api. what should i add in my data.
My sample data is as follows:-
{"fields":{"project":{"key": "TES"},"summary":"my bugs 5","description":"Hi","issuetype": {"name": "Bug"},
"customfield_10000":"roach#yahoo.com",
"customfield_10100":{"value":"abc"},
"reporter":{"name":"amit"},
"components": [{
"add" : {"name" : "abc"}
}],"priority": {
"id": "1"
}
}}
i want to use the names specified for customfields rather than customfield_XXXXX .
One way i think of is to hit the API after creating a simple issue ( using another API hit to get meta data as follows)
http://localhost:8080/rest/api/latest/issue/tes-79?expand=editmeta
and then do json parsing and again issue a put command to update the fields in same issue
but i was looking for a way to do it in single API hit (while creating an issue)
It should be just like setting any other field, but you have to use the field name "customfield_NNNNN" instead
I know that it is very late to answer this question, but then might help others if not the OP at this time of writing.
If you're in doubt about the create, then you could do something like this - Try a GET on an issue that you would rather create manually with the new parameters as well and then based on the output of the same you could then decide to update it with the new parameters with the new name or the old-fashioned customfield_xxx field.
Try a GET like this on cURL
curl -D- -u fred:fred -X GET -H "Content-Type: application/json" https://jira.fred.com/rest/api/2/issue/FRD-88651
Then you could possibly do a POST like how you've done earlier:
http://localhost:8080/rest/api/latest/issue
I'm fairly familiar with REST principles, and have read the relevant dissertation, Wikipedia entry, a bunch of blog posts and StackOverflow questions on the subject, but still haven't found a straightforward answer to a common case:
I need to request a resource to display. Depending on the resource's state, I need to render either a read-only or an editable representation. In both cases, I need to GET the resource. How do I construct a URL to get the read-only or editable version?
If my user follows a link to GET /resource/<id>, that should suffice to indicate to me that s/he needs the read-only representation. But if I need to server up an editable form, what does that URL look like? GET /resource/<id>/edit is obvious, but it contains a verb in the URL. Changing that to GET /resource/<id>/editable solves that problem, but at a seemingly superficial level. Is that all there is to it -- change verbs to adjectives?
If instead I use POST to retrieve the editable version, then how do I distinguish between the POST that initially retrieves it, vs the POST that saves it? My (weak) excuse for using POST would be that retrieving an editable version would cause a change of state on the server: locking the resource. But that only holds if my requirements are to implement such a lock, which is not always the case. PUT fails for the same reason, plus PUT is not enabled by default on the Web servers I'm running, so there are practical reasons not to use it (and DELETE).
Note that even in the editable state, I haven't made any changes yet; presumably when I submit the resource to the Web server again, I'd POST it. But to get something that I can later POST, the server has to first serve up a particular representation.
I guess another approach would be to have separate resources at the collection level:
GET /read-only/resource/<id> and GET /editable/resource/<id> or GET /resource/read-only/<id> and GET /resource/editable/<id> ... but that looks pretty ugly to me.
Thoughts?
1) It is perfectly valid to have two distinct resources, one for viewing and one for editing some domain concept. Just be aware that because they are two different URIs from REST's perspective they are two different resources. Too often people conflate resource with domain object. That's why they end up being stuck only doing CRUD.
2) Don't get too hung up on the name of the resource. The important thing is that you realize that what the URI points to is a "thing", "a resource". If that's more obvious to you with editable instead of edit then use that. Having a verb in your URL doesn't make your application wrong, it just makes it a bit less readable to the human developer. Using a verb in the URL to try and redefine the semantics of the HTTP method, now that's a violation of the uniform interface constraint.
In REST, editing an existing resource is accomplished by a client GET-ing a representation of that resource, making changes to the representation, and then doing a PUT of the new representation back to the server.
So to just read a resource your REST client program would do a:
GET http://www.example.com/SomeResource
And to edit that resource:
GET http://www.example.com/SomeResource
... edit it ...
PUT http://www.example.com/SomeResource
Normally simultaneous updates are handled by letting the last PUT arriving at the server overwrite the earlier ones, on the assumption that it represents a newer state. But in your case you want to guard against this.
Carefully consider #Jason's suggestion to maintain an optional parallel lock resource for each main resource. Your client would first create the lock, do the edit, then delete the lock. Your system would need to release a lock automatically if the user making the lock subsequently never saves any changes. This would look like:
GET http://www.example.com/SomeResource
... user presses an edit button ...
PUT http://www.example.com/SomeResource/lock
... user edits the resource's representation ...
PUT http://www.example.com/SomeResource
DELETE http://www.example.com/SomeResource/lock
You'd need to do some appropriate error handling if the user is trying to edit a resource that's locked by someone else.
It sounds like you feel you're constrained by the current limitations of HTML. If you use a server-side REST framework like Restlet (for Java), it supports the notion of "overloaded POST", where you can use POST but tack on a query string argument like method=PUT or method=DELETE. If you're writing your own server-side components they can use this trick too.
There are tricks you can play at the HTML level too. For instance your page can have a read-only part that's initially displayed, and an input form that's initially not shown. When the user presses the edit button, your JavaScript hides the read-only part and shows the input form.
Be sure to read Richardson and Ruby's Restful Web Services (O'Reilly) too. It's extremely helpful.
I don't think returning a form or just values is up to a REST server, but the responsibility of the client. Whether a resource is editable is a property of the resource, and not something defined by the URL.
In other words: The URL for getting the resource is GET /resource/<id>. This has a property editable. If a user wants a form it can retrieve the resource from the same URL and populate the form. The client can than PUT/POST changes.
How do I construct a URL to get the read-only or editable version?
There's an underlying problem here, which is that you are constructing URLs in the first place - appending IDs to hard-coded URLs is not REST. Roy Fielding has written about this very mistake. Whichever document prompts you to edit the resource should contain the URI to the editable variant of that resource. You follow that URI, whether that's /resource/editable or /editable/resource is outside the scope of REST.
If instead I use POST to retrieve the editable version, then how do I distinguish between the POST that initially retrieves it, vs the POST that saves it?
You perform a GET (not a POST) to read the resource, and POST (or PUT) to write the resource.
If you want to create a lock on the resource in question, use POST to write to the resource (or the resource's container, with the resource ID encoded in the body of the POST), and have the server create a lock as a new resource, and return an ID of that resource as the response to the POST. (with authentication issues beyond the scope of your question or this answer)
Then to unlock the lock, either use a DELETE on the lock resource, or POST to the lock's container.
I guess your question could be "how to identify the readonly representation that return with GET action in PUT action?". You could do this:
<Root>
<readonly>
<p1><p1>
...
<readonly>
<others>
...
<others>
<Root>
After parsing the request XML from PUT you can ignore the readonly part and process others. In Response, return 200 status and leave a message saying the part in readonly is ignored.
Is it your expected?