I am using Rexster to load data into a TitanDB. When posting / putting vertices, I can provide properties as JSON in the request's body. If a property's value is a number, it will correspondingly be stored as a number and can be retrieved as such. For example, the following body will in a post message will create a property "score" of type number:
{
"score": 5
}
When POSTing / PUTing edges, though, it seems properties can only be provided as query parameters, e.g.:
POST .../graphs/graph/edges?_outV=256&_label=review&_inV=512&score=5
In this case, unfortunately, the 5 is always considered as a string: "5". Consequently, queries including numeric operations / comparisons do not work. For example, the following query will still return the posted edge (despite the posted score being 5):
v(256).outE('review').filter{it.getProperty('score')>9}
Is there a way to POST / PUT edges and their properties so that the number type is considered?
I was reasonably sure you could POST JSON to the edge route, but even if you can't, you can use Rexster's explicit type system to post your integer properly:
$ curl -X POST "http://localhost:8182/graphs/tinkergraph/edges?_outV=1&_inV=2&_label=knows&score=(i,5)"
{
"version":"2.7.0-SNAPSHOT",
"results": {
"score":5,"_id":"0","_type":"edge","_outV":"1","_inV":"2","_label":"knows"
},
"queryTime":31.79554
}
Related
I have tried to create a record of my customized object through REST service in IBM Maximo.
The problem is that I created the record but I can't assign values to the attributes.
Next I will show what I did and what happened:
I have an Object Structure called oxidato that represents my customized object.
I did a POST using POSTMAN to this URL:
http://hostname:port/maximo/oslc/os/oxidato?lean=1
In the body section this is the JSON I was trying to send:
{
"attribute1":"205",
"attribute2":"206"
}
The record was created but none of the attributes was filled.
In my opinion, the REST service received the POST but can´t read the body.
What am I missing? I add an image of the POSTMAN as example:
EDIT1: I update the POST in order to use the newest API RES (Thanks Dex!)
EDIT2: I add an image of the header
I have found that Maximo will often ignore incoming attributes that aren't in the Maximo namespace (http://www.ibm.com/maximo). You could go through the trouble of setting up your VALOR1 and VALOR2 attributes to be in that namespace, but it's easier to just tell OSLC to ignore namespaces. You do that by setting the "lean" parameter to "1".
In your case, go to the "Params" tab and add an entry with a name of "lean". Give it a value of "1" and then send your POST again. You should see "?lean=1" appear at the end of the POST URL along the top there, but your body content should remain unchanged.
EDIT:
On the other hand, it looks like (based on your URL) that you aren't actually using the newer JSON/OSLC REST API; It looks like you are using the older REST services. This IBM page gives you a lot of information on the newer JSON REST API, including the correct URLs for it: https://developer.ibm.com/static/site-id/155/maximodev/restguide/Maximo_Nextgen_REST_API.html.
You should change your URL to /maximo/oslc/os/oxidato to use the newer API that naturally supports JSON and the lean parameter described above. This does required Maximo 7.6 to use though.
EDIT 2:
The attributes are often oddly case sensitive, requiring lowercase. Your example in your question of "attribute1" and "attribute2" are properly lowercase, but your screenshot shows uppercase attribute names. Try changing them to "valor1" and "valor2". Also, these are persistent attributes, right?
The response code received back (e.g. 200 - OK) and the response body will detail the record that was created.
I think you are correct in that the body of the post request is being ignored. Provided there are no required fields on the custom MBO your POST is probably creating an empty record with the next value in the sequence for the key field but you should see that in the response.
The following POST should create a record with values provided for attribute1 and attribute2 and provide a response with the record's identifier so that you can look it up in Maximo and show the values that were stored for attribute1 and attribute2:
http://hostname:port/maximo/rest/os/oxidato/?_format=json&_compact=1&attribute1=205&attribute2=206
Response: 200 OK
Reponse Body:
{ "CreateOXIDATOResponse": {
"rsStart": 0,
"rsCount": 1,
"rsTotal": 1,
"OXIDATOSet": {
"OXIDATO": {
"rowstamp": "[0 0 0 0 0 -43 127 13]",
"ATTRIBUTE1": "205",
"ATTRIBUTE2": "206",
"OXIDATOID": 13
}
} } }
You may also want to turn on debug logging for the REST interface in System Configuration -> Platform Configuration -> Logging for additional detail on what's happening in the log file.
Problem
I want to retrieve specific data from Google Firestore.
It's only possible to get all of the 'Fields' data. But no specific data within fields
Example of the GET-Request:
https://firestore.googleapis.com/v1beta1/projects/edubox-49528/databases/(default)/documents/nodes/EduBox-1234567?key=[My_API_KEY]&fields=fields
As you can see, It is possible to obtain all the items in the object 'Fields'. But it is not possible to get any further into detail to obtain more specific data (test, message, nodeID, ...)
Tryouts
I have already tried:
fields=fields/test
fields=fields.test
fields=fields(test)
fields=fields/test/integerValue
...
Expected Results
I want to obtain specific data like the String / integer value of my objects in 'Fields'.
This example should return the integerValue with 30
https://firestore.googleapis.com/v1beta1/projects/edubox-49528/databases/(default)/documents/nodes/EduBox-1234567?key=[My_API_KEY]&fields=fields/test
This example should return 30
https://firestore.googleapis.com/v1beta1/projects/edubox-49528/databases/(default)/documents/nodes/EduBox-1234567?key=[My_API_KEY]&fields=fields/test/integerValue
Solution
While browsing the web, I came across Google Api Explorer:
https://developers.google.com/apis-explorer/#search/firestore/firestore/v1beta1/
When trying out some possibilities, I came across this:
https://firestore.googleapis.com/v1/projects/edubox-49528/databases/(default)/documents/nodes/EduBox-1234567?mask.fieldPaths=nodeID&fields=fields&key={YOUR_API_KEY}
This gives me the right information
but I still need a more detailed form of this answer like only the 'EduBox-1234567'
The way to retrieve a specific field is to use mask.fieldPaths. For example the following GET method:
https://firestore.googleapis.com/v1beta1/projects/edubox-49528/databases/(default)/documents/nodes/EduBox-1234567?key=[My_API_KEY]&fields=fields&mask.fieldPaths=nodeID
is going do return:
{
"fields": {
"nodeID": {
"stringValue": "EduBox-1234567"
}
}
Documentation references here and here.
I have two SharePoint lists used for Support case management. The first list contains Case Numbers and information about the case. The second list contains exhibits that support the case itself.
We have a convention that the Case Number is a String supplied by the worker, ex 20150205-001. When the exhibits are joined to the Case it is through a Lookup. I want the Exhibit ID, a String, to be of the form Case Number + _[A-Z] -- and be auto-assigned.
I want to use a Workflow (MS Sharepoint Designer 2013) to assign the Exhibit ID. The problem I face is that I cannot get the actual Case Number from the Lookup. The closest I have gotten so far is to get the ID (1, 2, etc) but not the actual String value represented.
Tried working with the following URL:
http://[mySiteURL]/_api/web/lists/getbytitle([listName])/items?$select=Title,Case/Id&$expand=Case/Id&$filter=Case/Id%20eq%2020150205%45001
substituted ascii: $filter=Case/ID eq 20150205-001
without the filter I get all list items (understandably) but the filter does not work properly because the ID is not the actual lookup value.
This is a SPD 2013 limitation. You have to use a web service call from within Designer to get the specifics of a lookup column from SharePoint. You make a REST call ad then parse the JSON response for the specific data from the lookup column. It gives you access to all of the columns from the list item that you looked up:
Build {...} Dictionary (Output to Variable: requestHeader )
Call [%Workflow Context:Current Site URL%]... HTTP web service with Variable: Request (ResponseContent to Variable: PoleIDData |ResponseHeaders to Variable: dictionary |ResponseStatusCode to Variable: responseCode )
Get d/Pole_x0020_ID from Variable: PoleIDData (Output to Variable: PoleID )
Set Name to Variable: PoleID
Your actual web service call will be formatted like this:
[%Workflow Context:Current Site URL%]/_api/web/lists/GetByTitle('List Name')/Items([%Current Item:ID%])/LookupColumnNameOnOtherList
Sorry for the formatting, I would post a screenshot but I cannot.
This article is good for showing you some of the other specifics about formatting your HTTP Request, especially the Request Headers which must be setup right.
http://www.fiechter.eu/Blog/Post/37/SharePoint-2013--HTTP-Web-Service-Action---Use-Managed-Metadata-as-Text-in-Workflow
Say we have the following server resource:
api.example.com/event/1
Which returns some arbitrary resource, say:
{
id: 1,
details: {
type: 'webinar',
....
},
attendees: [
{
user_id: 1,
first_name: 'Bob'
...
},
...
]
}
It might be useful for a client to make a request to get just the event details of the event but not the list of attendees.
Is it better to provided two separate URLs for the resources and force two separate requests if a client wants both resources?
api.example.com/event/{event_id}
api.example.com/attendees/{event_id}
Or is it better to offer the same two endpoints, but optionally have the first one support a GET param to toggle the attendee listing on or off
api.example.com/event/{event_id}?listAttendees={true|false}
api.example.com/attendees/{event_id}
Where the listAttendees parameter will either have the representation return the attendee list or not.
Is it an common practice to allow GET params to change the representation returned from a specific URL?
I'd say the most correct way to do that in REST would be with different media-types, or media-type parameters, but since most people don't use custom media-types, I often use something I call the zoom protocol. The idea is that you have a zoom or expand parameter, with a numeric value, and it recursively includes the children entities, decreasing the parameter until it reaches zero.
So, a request like:
GET api.example.com/event/1
Returns the plain representation for the event resource, without embedding anything. A request like:
GET api.example.com/event/1?zoom=1
Would include the immediate children of event, in your case, the atendees. Following on that:
GET api.example.com/event/1?zoom=2
Would include the immediate children of event, the immediate children of atendees.
To answer your question, in REST the whole URI is an atomic identifier, so the parameters are part of the URI. That can be a problem if you're using something that won't interpret URIs in the same way, like old cache servers who won't cache URIs with a querystring.
Suppose I have to implement game character resource. Character could have only one weapon.
Weapon types are different (sword, knife, gun etc.) and have different set of properties.
Character and Weapon are separate resources for sake of usability.
In OOP model it will looks as follows
What will be the best way to design URIs and resources for such structure?
edit:
In general. Is it ok to have in Character resource link to weapon resource that return Knife, Sword or Gun or it have to be the link to certain resource such as http:\game.com\character\sword?
In general, the REST model can be mapped directly as "Object" <-> "Representation" and "OID/References" <-> "URI". So first, what you have to do is to assign each of the elements present in the game a different URI.
Option 1
Say you use JSON to describe the character, so you would have something like this:
URL: /character/Warrior
Content:
{ "name" : "Warrior", "weapon" : "/weapons/id_of_weapon" }
Note how the "weapon" includes a link (or an array of those) to the different weapons that the character has. Each of those, following the REST principle, is identified by an URI.
You have now two options to suport the type/subtype variation:
Use different MIME types
When you obtain the resource /weapons/id_of_weapon, you'll get, say, a response from the server in which the headers look like this:
HTTP/1.1 200 OK
...
Content-Type: my-game/Knife
... (more headers)
Knife data Content
This identifies the actual type of the element returned, and can be used to map it to the different subtype. You can use different schemes, such as Weapon/Knife, or MyGameObject/Weapon_Knife.
Use content-based object mapping
Also, you can explicitly set the type of the returned instance. In this case, you could get a response like this:
HTTP/1.1 200 OK
...
Content-Type: application/json
... (more headers)
{ "type" : ["Weapon", "Knife"] , ... (rest of fields) }
Note how the type JSON parameter is used as a standard in your game to specify the different types supported by that returned data.
Option 2
You may also consider, after your edit, that you can mimic the resource containment architectur in URIs. However, you propose http://whatever/character/sword. This is not appropriate, because you're naming classes, and not resources. A more appropriate URL scheme would be something like:
http://whatever/character/idc/weapon/idw
where idc and idw are the identifiers of the character and the weapon respectively. Note that you don't fix the exact type of the weapon in the resource URI (that is, you have to say weapon, not knife), but it may happen that actually the weapon with the id idw is actually of type Knife (using either of the options given above).
If you map containment to URIs, you can also have a more compact format for the character as follows:
{ "id": "idc",
"name" : "Warrior",
"weapon" : { "id": "idw", "type": "Knife", (rest of knife properties) }
}
Note how: each element has its own id. Containment is observed via JSON recursive object inclusion, you also specify the type of the weapon, and, still you can map the URL scheme just described to access the inner elements of the character.