Related
According to the HAL standard (see here and here) the links to other resources should be placed in a specific embedded section.
So for instance this is not valid HAL, is my understanding correct?
{
"movies": [
{
"id": "123",
"title": "Movie title 1",
"_links": {
"subtitles": {
"href": "/movies/123/subtitles"
}
}
},{
"id": "456",
"title": "Movie title 2",
"_links": {
"subtitles": {
"href": "/movies/456/subtitles"
}
}
}
],
"_links": {
"self": {
"href": "/movies"
}
}
}
The reason for which the above JSON is not valid HAL is that the links should be placed in an embedded section ("_embedded") that links to the ID in the main body. So the right approach would be:
{
"movies": [
{
"id": "123",
"title": "Movie title 1",
},{
"id": "456",
"title": "Movie title 2",
}
],
"_embedded": {
"movies": [
{
"id": "123",
"_links": {
"href": "movies/123/subtitles"
}
},
{
"id": "456",
"_links": {
"href": "movies/456/subtitles"
}
}
]
}
"_links": {
"self": {
"href": "/movies"
}
}
}
Is all the above correct?
Thanks
Gonna use this as a case study on re desiging with hal. #darrel millers answer is good, but not great and has some things i think should be cleared up. this is gonna be LONG.
The big question is what is the context...IE what is this resource you are returning. All you've got is something that relates to movies somehow. Like suppose this is a search result...having a movie relationship is the wrong approach..as the movie relates to the search result "top level resource" as an item. so it should be something more like
{
title : "Results for search XXXXX"
_links : {
self : { href: "https://host.com/search/with/params/XXXXX"},
item : [
{ href : "https://host.com/url/to/movie/result/one", title : "A great Movie"},
{ href : "https://host.com/url/to/movie/result/two", title : "A Terrible Movie"},
]
}
}
but this structure would be expensive for a client to construct a UI around as it would have to make 3 calls..following the N+1 rule (1 for the result set..then N for each result) so thus was born _embedded which is just hal implementation of the hypertext pre fetch pattern (in http2 the server could actually send each result as it's own document and the client's cache would be pre-filled with those results and you wouldn't necessarily need _embedded). That structure looks more like this:
{
title : "Results for search XXXXX"
_links : {
self : { href: "https://host.com/search/with/params/XXXXX"},
item : [
{ href : "https://host.com/url/to/movie/result/one", title : "A great Movie"},
{ href : "https://host.com/url/to/movie/result/two", title : "A Terrible Movie"},
]
},
_embedded : {
item : [
{
_links : {
profile : {href : "https://host.com/result-movie"},
canonical : {href : "https://host.com/url/to/movie/result/one"}
},
title : "a great movie",
rating : "PG",
},
{
_links : {
profile : {href : "https://host.com/result-movie"},
canonical : {href : "https://host.com/url/to/movie/result/two"}
},
title : "a terrbile movie"
rating : "G",
}
]
}
}
That's pretty great 1 http request to get 3 resources. 1 request not N+1. Thank you HAL!
So why item? well does the search result ONLY EVER contain movies...that's very unlikely..and even if it does today...do you want it to only ever contain movies tomorrow...that's pretty narrow and this structure is a contract that you have to maintain basically forever. But your UI really wants to show the result as a movie. That what the profile link i've added is for...the client uses the profile link to know what the resource it's currently processing is..and what fields it can use to build up a UI. A decent client when processing a collection displays what profiles it can..and just ignores what ones it can't (logging a warning maybe). It up to the client dev to upgrade their app to support new profiles...don't believe me? think about how a web browser parses tags it doesn't understand in html...put a <thing-not-invented-yet></think-not-invented-yet> in your html doc and see how a good client works.
another thing you should notice is i do NOT use self links but canonical..i've changed my stance on this over the years. as of late i default to canonical and i ONLY use self when I'm maintaining versions of the target resource and it's important to have the embedded object link to the specific version that was embedded. this is very rare in my experience. I tell clients to follow self it it's present, ortherwise follow canonical when navigating to the embedded item. this gives the server complete control on where it wants to take the client. The top level resource, in this case a result should still have a self...and in this case it makes sense as soem random search probably does not have a canonical link...unless it's a VERY common keyword search...then it probably should as other users could use the same url.
Let take a moment to talk about why item as the rel...cause this is really important. Since it's a search result..why not have the rel be result. There's a really easy answer..result is not a member of the IANA link registry https://www.iana.org/assignments/link-relations/link-relations.xhtml and therefore result is completely invalid...now you could "namespace" your extension rel with my:result or our:result (the "namespace" is up to you, these are just example) but why bother with that if a perfectly good one already exists in the IANA registry..and it does item.
Let's talk about items vs item (or x:movies vs x:movie) . Well items isn't in IANA either..so it'd have to be x:items but instead of doing that let's think about why. If our result doc was represented in HTML it'd be looking like this (ignore my missing body head etc not well-formedness for brevity):
<html>
<title>Results for search XXXXX</title>
<a rel="item" href="https://host.com/url/to/movie/result/one" >A Great Movie</a>
<a rel="item" href="https://host.com/url/to/movie/result/two" >A Great Movie</a>
</html>
This is the SAME resource as the first example (without embedding sub resources). Just represented as text/html and not application/hal+json. If i've lost you here (this is where most people get REALLY confused, the best i can offer is to watch my talk on this at https://www.youtube.com/watch?v=u_pZBBELeEQ ) Hear it's clear the appropriate relationship of each target resource is a SINGLE ITEM and not a set of ITEMS. each link targets one item (or one, singular movie).
There's a trap with HAL to treat it like JSON and that leads to statements like the one the comments that movies is machine readable or better. Let me explain how this comes about by continuing with this HTML representation in a use case.
When a client parses this document looking for item links it must parse EVERY a tag and filter down to only those where rel="item" attribute is present. That's a "full table scan"..and how do we get away from those? we create an index. JSON has the concept of an index built into it's structure. It's a key with an array value. index : [ {entry 1}, {entry 2} ]. The author of HAL knew the most common way to retrieve links (in _links or the prefetched ones in _embedded) would be by relationship..so he structured his spec such that rel is indexed. so when you see:
_links : {
self : { href: "https://host.com/search/with/params/XXXXX"},
item : [
{ href : "https://host.com/url/to/movie/result/one", title : "A great Movie"},
{ href : "https://host.com/url/to/movie/result/two", title : "A Terrible Movie"},
]
},
know that it is REALLY
_links : {
self : { rel: "self", href: "https://host.com/search/with/params/XXXXX"},
item : [
{ rel:"item", href : "https://host.com/url/to/movie/result/one", title : "A great Movie"},
{ rel:"item", href : "https://host.com/url/to/movie/result/two", title : "A Terrible Movie"},
]
},
because the rel is an attribute of the LINK OBJECT and NOT THE RESOURCE. but bytes over http are expensive (gzip would get rid of this) and devs don't like redundancies (a whole other topic) so when we have hal we OMIT the rel attribute since the HAL structure already makes the rel apparent. though it's not really apparent when your parser encounters just this:
{ href : "https://host.com/url/to/movie/result/one", title : "A great Movie"}
what's the rel? you have to pass that in from the parent node..that's always been ugly...anyways all this is to show that redundancy is eliminated in HAL generally. once this redundancy is eliminated it's tempting to change that index key to the plural form items but know that would mean you are saying your link (once redundancies are PUT BACK) would be {rel: "items", href : "https://host.com/url/to/movie/result/one", title : "A great Movie"} and that is clearly wrong..that link is not to many items...just one.
So removing redundancy in this case probably wasn't the best..but it's evil with benefits and HAL follows that pattern for _links and _embedded and that's what we're gonna do with our search result..given that ALL the item links have no been pre-fetched and are present as _embedded it's unimportant to keep them in _links. and as such it should look like this:
{
title : "Results for search XXXXX"
_links : {
self : { href: "https://host.com/search/with/params/XXXXX"}
},
_embedded : {
item : [
{
_links : {
profile : {href : "https://host.com/result-movie"},
canonical : {href : "https://host.com/url/to/movie/result/one"}
},
title : "a great movie",
rating : "PG",
},
{
_links : {
profile : {href : "https://host.com/result-movie"},
canonical : {href : "https://host.com/url/to/movie/result/two"}
},
title : "a terrbile movie"
rating : "G",
}
]
}
}
Now we have a pretty good search result that includes 2 movies (and can include more things in the future without breaking the contract). Note: if you ever went live with JUST _links and no _embedded...you can NOT remove the _links as some client out there is depending on them being present..so it's best to think of this stuff early...thought a well behaving client should always check _embedded before _links when using the HAL representation of a resource...so it's really up to you to know if all your clients are well behaving.
Ok so let's move to a case where x:movie is the correct relationship..that probably would be good if the top level resource is an actor. so something like:
{
Name : "Paul Bettany"
_links : {
canonical : { href: "https://host.com/paul-bettany"},
"x:movie" : [
{ href : "https://host.com/url/to/movie/result/one", title : "A great Movie"},
{ href : "https://host.com/url/to/movie/result/two", title : "A Terrible Movie"},
],
"x:spouse" : { href: "", title: "Jennifer Connely"}
},
_embedded : {
"x:movie" : [
{
_links : {
profile : {href : "https://host.com/result-movie"},
canonical : {href : "https://host.com/url/to/movie/result/one"}
},
title : "a great movie",
rating : "PG",
},
{
_links : {
profile : {href : "https://host.com/result-movie"},
canonical : {href : "https://host.com/url/to/movie/result/two"}
},
title : "a terrbile movie"
rating : "G",
}
]
}
}
Notes: i used canoncial instead of self at the top level because an actor is long-lived resource..that actor will always exist..and an actor is not versioned. For completeness i left both x:movie in _links and _embedded, however in practice i would NOT have the ones in _item. I also kept them in _links to show the reasons to have x:movie is so that you can differentiate it from x:spouse (that semantic differentiation did NOT make sense in the search result case we started with). Finally it's useful to note that i embedded x:movie but NOT x:spouse this is just to illustrate that it is not an either / or thing. you can pre-fetch/embed the link you need for your use case. In fact i often embed things based on the identity of the client..ie i know iOS can display something that android can not.
Those notes aside, the reason i went here is that i wanted to make it clear that you do NOT and SHOULD NOT have that movies: data field that you have...just rely on the movie data in _embedded. You said soemthign like matching up the values in the movies to teh ones in _links or _embedded...you should NOT be doing that..that doesn't make any sense. a movie is a resource...use the linked resource of a movie not some data field. You need to decide early on what is a resource and what is a piece of data. my best tip is if a thing has link relationships..then it's a resource. In my talk i go into MUCH MORE DETAIL on this with broader terms (hypermedia controls) that i don't want to get into here yet.
A final note..in hypermedia applications you KNOW you are doing something wrong if you are exposing internal id fields..as you have done here. That should be a huge red flag that something is wrong. The use case for the id's you described was to match up the data field movies with the _embedded x:movie. As stated...you should NOT be doing that..and the presence of an id field should key you in to that bad practice.
I was asked to answer here..so i hope this helps.
The "_Links" property must go in the root of a resource object. That resource object might be at the root, or it could be in the _embedded object.
I suspect some of the confusing is coming from having an "_embedded" key point to an array. This is only done when you want to represent multiple instances of a related resource.
In the example the key is movies which infers you are embedding a resource object which represents multiple movies. However, the array indicates there are multiple embedded resource objects. Each resource object is one movie.
By changing the name of the key to "movie" you get this:
{
"movies": [
{
"id": "123",
"title": "Movie title 1",
},{
"id": "456",
"title": "Movie title 2",
}
],
"_embedded": {
"movie": [
{
"id": "123",
"_links": {
"href": "movies/123/subtitles"
}
},
{
"id": "456",
"_links": {
"href": "movies/456/subtitles"
}
}
]
}
"_links": {
"self": "https://example.org/movielist"
}
}
So, now you have a representation of a "movie-list" resource object and you have embedded a bunch of "movie" resource objects for each item in the "movie-list". Each resource object pointed to by "movie" has a "_links" property to related information. I'm assuming that "subtitles" link was supposed to be a self link.
As observable in the specs you posted, you can have links and/or embedded resources:
A resource's links should sit as a property of that resource:
{
"movies": [
{
"id": "123",
"title": "Movie title 1",
"_links": {
"subtitles": {
"href": "/movies/123/subtitles"
}
}
}, {
"id": "456",
"title": "Movie title 2",
"_links": {
"subtitles": {
"href": "/movies/456/subtitles"
}
}
}
]
}
The alternative would be to directly embed the movie's subtitles resource:
{
"movies" : [
{
"id" : "123",
"title" : "Movie title 1",
"_embedded" : {
"subtitles" : [{
"name" : "movie 1 subtitles"
}
]
}
}, {
"id" : "456",
"title" : "Movie title 2",
"_embedded" : {
"subtitles" : [{
"name" : "movie 2 subtitles"
}
]
}
}
]
}
Recently I was trying to implement scenario where I could link views in 3D viewer with views on original revit model.
I zipped linked files and upload them
Upload more times same zip file with changed rootFileName to provide all aspects of a model and translate all
download their manifest.jsons
link views on revit side with view in the viewer using viewableID and uniqueID of original revit view
In here I will provide real shortened examples of manifest outputs
eg file 1.
{
"guid" : "578dd62c-d5dc-8da0-1c75-aa6b0be8ba76",
"name" : "3D pohled",
"success" : "100%",
"hasThumbnail" : "true",
"status" : "success",
"type" : "folder",
"progress" : "complete",
"children" : [{
"guid" : "07e30540-b182-cd58-1c1f-eb46bc58fb9c",
"name" : "{3D}",
"success" : "100%",
"size" : 771479.0,
"hasThumbnail" : "true",
"role" : "3d",
"viewableID" : "8af1141e-a7ca-22b4-d104-d7331a1c0454",
"status" : "success",
"type" : "geometry",
"progress" : "complete",
"children" : [{
"guid" : "429ba882-f0a0-40fa-96e6-c6e02d9fc601-00022cda",
"name" : "{3D}",
"role" : "3d",
"camera" : [22586.240234, 40687.59375, 32810.621094, 54.133858, -29.527559, 16437.923828, -0.160696, -0.29039, 0.943319, 0.547078, 0, 1, 1],
"status" : "success",
"type" : "view",
"progress" : "complete"
}, {
"guid" : "9a3b544b-3c15-9304-f6f8-2c4db7a7dcb3",
"type" : "resource",
"role" : "graphics",
"urn" : "urn:adsk.viewing:fs.file:dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6dGVzdGJfMTIzZWUvRkhfRmFzJUMzJUExZGFfdi4wMS56aXA/output/Resource/3D_pohled/_3D_/_3D_.svf",
"mime" : "application/autodesk-svf",
"size" : 680482.0
}
]
}
]
}
eg. file 2
{
"guid" : "578dd62c-d5dc-8da0-1c75-aa6b0be8ba76",
"name" : "3D pohled",
"success" : "100%",
"hasThumbnail" : "true",
"status" : "success",
"type" : "folder",
"progress" : "complete",
"children" : [{
"guid" : "07e30540-b182-cd58-1c1f-eb46bc58fb9c",
"name" : "{3D}",
"success" : "100%",
"size" : 7648740.0,
"hasThumbnail" : "true",
"role" : "3d",
"viewableID" : "8af1141e-a7ca-22b4-d104-d7331a1c0454",
"status" : "success",
"type" : "geometry",
"progress" : "complete",
"children" : [{
"guid" : "429ba882-f0a0-40fa-96e6-c6e02d9fc601-00022cda",
"name" : "{3D}",
"role" : "3d",
"camera" : [40927.800781, 19529.832031, 36075.765625, 54.958988, -27.723097, 16418.119141, -0.359014, -0.171787, 0.917387, 0.320998, 0, 1, 1],
"status" : "success",
"type" : "view",
"progress" : "complete"
}, {
"guid" : "9a3b544b-3c15-9304-f6f8-2c4db7a7dcb3",
"type" : "resource",
"role" : "graphics",
"urn" : "urn:adsk.viewing:fs.file:dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6dGVzdGJfMTIzZWUvRkhfVFpCX1ZaVC56aXA/output/Resource/3D_pohled/_3D_/_3D_.svf",
"mime" : "application/autodesk-svf",
"size" : 7552662.0
}
]
}
]
}
as you see each time URN of file is different, still viewableID and guids are the same. This is not suppose to happen and represents a real problem when working with the information. In manifest.json is also missing information about original revit guid(uniqueid) from which view it was generated, which is needed to uniqely identify view on revit side.
I think it is a bug and needs to be solved and also adding revit view guid into output manifest would help a lot. Because name property is not unique enough, the other guids has no practical use.
Any help would be greatly appreciated
The ids will be the same if they are translated from the same file (i.e. the unique ID used by Revit on its views), regardless the file name. So if you have a .rvt with a view, duplicate this file with different name, translate them both, they will have the same id on that view.
EDIT October 17, 2016
We have updated the translation engine in 9/26/2016 and the viewableID in the bubble is the same as the UniqueId of a Revit View, for both 3d and 2d. That way you can use the viewableId to implement your feature feature.
It is reasonably well known that Revit elements' "unique" ids are not, in fact, true GUIDs. Two copies of a file will have exactly the same "unique" ids for the elements in those files (they are not re-generated on a save-as operation). The purpose of the Unique id in Revit was to provide a mechanism to facilitate worksharing where element ids are not "stable" and may change during a reload latest event where element ids from the central conflict with local Element Ids.
Here is some information from The Building Coder about this topic:
http://thebuildingcoder.typepad.com/blog/2014/04/element-id-export-unique-navisworks-and-other-ids.html#3
In terms of your specific question: "How can i identify, uniquely, the views in revit when traversing manifest.json?" I would suggest that you might (if you have the ability) add the Revit filename as part of the name of the exported view which you have uploaded and translated. Tease that back out of the URN to determine which view you actually have.
If that doesn't work, maybe you could help us better understand this statement:
Upload more times same zip file with changed rootFileName to provide all aspects of a model and translate all
what is this attempting to achieve? different implementations on the viewer side of the same view data? And if so, maybe you can tell us more about exactly what you're trying to ultimately achieve and we can offer some more specific suggestions.
I am planning to move some of my RDBMS tables to a NoSQL environment. I have different modules and associated tables as shown below.
1. General
News table
Trainings table
Knowledge table
2. Application_x
Clicks table
Crashes table
Note : This is a sample scenario
In this case, this is how i defined Nosql (Couchbase server) structure. Please correct me if this is wrong.
The purpose of migration is mainly intended for searching.
{
"General":[
"news" : [{
"id" : "123",
"title" : "test title"
},
{
"id" : "345",
"title" : "test title 2"
}],
"trainings" :[{
"id" : "1",
"name" : "training 1"
},
{
"id" : "2",
"name" : "training 2"
}],
"knowledge" :[{
"id" : "1",
"categ" : "programming"
},
{
"id" : "2",
"categ" : "management"
}]
],
"Application_x": [
"clicks" : [{
"userid" : "1",
"area" : "1850",
},
{
"userid" : "2",
"area" : "258",
}],
"crashes" :[{
"userid" : "1",
"severity" : "1",
},
{
"userid" : "2",
"severity" : "8",
}]
]
}
Can someone correct me if my approach is not correct ?
Thanks in advance,
Tismon Varghese.
By reading your question, I am left scratching my head as to what your approach is. In a NoSQL database (such as couchbase) - you don't have the idea of tables and columns. Each object is serialized to JSON and stored in plain text. Yes, this creates duplication, but the drawbacks of duplication are greatly outweighed by the benefits of scalability.
In this example, using Couchbase, you would probably want to create one Couchbase bucket per application. That way, should you need to migrate to a different Couchbase cluster at a later date, a minimal amount of configuration is required. Each row in your tables gets created as a separate object in Couchbase. There is no need to separate the object types within the bucket.
This blog entry contains some detailed instructions on how to migrate from mySQL to Couchbase.
On a side note, I might recommend using Couchbase combined with Elasticsearch.
I want to get json from url in google app engine, can u tell me some quite simple methods to do this, thanks, sr my english not good
URL
Content:
{
"debug_info" : [],
"html_attributions" : [ "Listings by \u003ca href=\"http://www.diadiem.com/\"\u003eDiadiem.com\u003c/a\u003e" ],
"next_page_token" : "ClRMAAAAl7MjfntXhFEi33IPPcZJJ5fYfiJzIIGggr9Xc6A_sKeTrjohJntaaG1jWaGYMKiZYruuoqTVipUZFaLhpNXZbhYloN6SeS44epx3lPRdpuMSEHWJTSO2ShwXOz6bjg0xefcaFOUN9wK6NE5Dykjx-x-VLypkBMRH",
"results" : [
{
"geometry" : {
"location" : {
"lat" : 16.058660,
"lng" : 108.2191410
}
},
"icon" : "http://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png",
"id" : "7064cb3f44db62207fc2bd83579b63ca9552e658",
"name" : "Vietcombank - Atm",
"reference" : "CnRwAAAAHU3y6j7CocExwcFq6DKtkS2SFT-0X23E7C9M7bpHk2EF04ShIX7IRNl9TwGF_APSwaKmk8XSZIGm52ajXnpKhj15i48w0BHmJR0ZamJdIAi3iJD_sExjjHkf5Lnfxq4iLroTAmQyRAoAVG7dMwVeTRIQcO_Qq9N85d96vQCtEdZjyRoUbETiZPHxkSjkbD9CVnQh6N_8yUA",
"types" : [ "establishment" ],
"vicinity" : "272 Phan Châu Trinh"
},
{
"geometry" : {
"location" : {
"lat" : 16.0602490,
"lng" : 108.21470
}
},
"icon" : "http://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png",
"id" : "bd20b9fbd718c13ee3f6d404c3004b649130df4a",
"name" : "ATM DongA Bank",
"reference" : "CnRtAAAAP9XTDfjgtqvahglz24j2posRRCR9ry56xyAd0FX810ZeyiKWeEi4Btfnfycb23Sa6x_grdjJszB7Xf80jFBrer9kHYQHsKX2-spx9LHn_yrZxlfC7wxHOdUt9YbYMp71fzQ_SJOC9W1Hj2cHHi9g0BIQPrdWzJvelD1NDEcC49Q8eRoUE0juanyzeZHjyYbnozUGB13RySk",
"types" : [ "atm", "finance", "establishment" ],
"vicinity" : "Nguyễn Văn Linh, Da Nang"
},
Not sure if I got your question correctly, but if you are trying to parse Google's JSON response, a good and easy way to do it may be to use jQuery parseJSON function.
You can also take a look at this answered question to see sample code.
Also, not explicitly stated in the "answered question" link above - you cannot just access the json (or xml) from within your web page code even though you can use the url manually in a browser to get the json data (as it seems you have done in your post). There are various security aspects and Google will not even send the data requested that way (I believe it is call cross-site-scripting - Google it for more details). It has to go - as in the example linked above, from you web page to your server, have the server do the request to Google to get the data, have the server then post this back to your site/ web page (through AJAX or just a new page - however you are doing things on your site).
That's the sloppy and non-technical, but I wasted all day Sunday trying to get around this until I understood the issue and what I was supposed to (and had to do). This might not be what you are referring to but I think it may indeed be. If so I hope it helps. Cheers
Hi I am trying to add documents to a cloudsearch domain as per
http://docs.pythonboto.org/en/latest/cloudsearch_tut.html#adding-documents-to-the-index
my code snppet is:
import boto
conn = boto.connect_cloudsearch(aws_access_key_id='<>',aws_secret_access_key='<>')
domain = conn.lookup('testfoo')
doc_service = domain.get_document_service()
doc_service.add(doc_id, version, data)
First I got the same requests issues
Boto CloudSearch on GAE: TypeError: request() got an unexpected keyword argument 'config'
and so I removed the config kwarg (also not sure of the consequences)
and then I get
boto.cloudsearch.document.CommitMismatchError: Incorrect number of adds returned. Commit: 1 Response: 0
My data is like this
[
{
"raw" : "whole bunch of raw text",
"title" : "My new title",
"blurb" : "A really exciting article",
"document_type" : "Tech Guide",
"url" : "http://www.foobar/7199/tech-advice"
}
]
Any help greatly appreciated
It turns out the problem is when I built up the json in data it is not json but a string. So when this produces the json being sent to the cloudsearch domain and it combines the id and "Add" operation it includes "fields": "[
{
"raw" : "whole bunch of raw text",
"title" : "My new title",
"blurb" : "A really exciting article",
"document_type" : "Tech Guide",
"url" : "http://www.foobar/7199/tech-advice"
}
]" as a string
The solution is simply data needs json encoding
doc_service.add(doc_id, version, json.loads(data))
Here just remove [] from data. Because if you have single object then you must pass it with dictionay. {}
[
{
"raw" : "whole bunch of raw text",
"title" : "My new title",
"blurb" : "A really exciting article",
"document_type" : "Tech Guide",
"url" : "http://www.foobar/7199/tech-advice"
}
]