Below, in reverse chronological order, you’ll find the API changes we’ve made to Fluidinfo. The icon is used to indicate changes that are not backward compatible.
Please note that this change log is deliberately brief. To fully understand the changes and how they may affect your code, please follow the links to the relevant details.
The Fluidinfo sandbox has been deactivated as it was only in very light use and was not being maintained as regularly as we had intended.
This new endpoint allows the user to get information about the latest tag values created on a particular object or by a particular user.
Objects representing Fluidinfo users now will use the @<username> pattern for fluiddb/about value instead of the old Object for the user named <username> pattern. All the values on the old objects have been migrated.
The following queries are now illegal in Fluidinfo: has fluiddb/about and fluiddb/about matches "". These queries produce too many results.
An updated-at has been added to the response value of /values GET showing an ISO 8601 datetime string with the last modification date of a given value.
It was not possible to send Cross-Origin Resource Sharing (CORS) requests to Fluidinfo using a Webkit based browser because of a pre-flight request problem.
Webkit based browsers only allow headers listed in the Access-Control-Allow-Headers header returned in the pre-flight request to be used in the subsequent request. According to the CORS specification Content-Type does not need to be listed in Access-Control-Allow-Headers and should work no matter what. This is a bug in Webkit browsers.
Unfortunately, the side effect was that CORS requests didn’t work for users of such browsers, so we’re now including Content-Type in the header as part of the pre-flight response. Thanks to IRC user ErrGe for pointing out this problem.
Fluidinfo was giving a 400 (Bad request) error for /about requests with double quotes in the about value. E.g., GET /about/the%20"best"%20idea. This has been fixed.
The GET and HEAD methods on /objects and /about used to get a primitive tag value now contain an X-FluidDB-Type header indicating the type of the requested value. Details. Many thanks to Xavier Noria for suggesting this change.
We have stopped using the name FluidDB, in favor of Fluidinfo. The documentation has been updated accordingly. For the reasoning behind this change, please see the blog post announcement.
The id key was being left out in the response dictionary for GET requests on /values.
We have simplified the permissions system slightly and are now using only the READ permission on tags to decide whether API calls accessing tag values should be allowed to proceed. Anything that used the SEE permission now uses READ. E.g., when you do a GET on an object to retrieve the names of its tags, you will only receive those for which you have READ permission. Many thanks to Jamu Kakar for suggesting this simplification.
It is now possible to manipulate multiple tag values in a single API request to /values. Details.
Trying to DELETE a tag value from an object that did not have that tag formerly resulted in a 404 (Not found) status. This has been changed to simply return the non-error 204 (No Content) status of a DELETE in which the tag was present on the object.
It is now possible to access Fluidinfo objects that have a fluiddb/about tag via HTTP requests to URI that start with /about. For example, the object about Barcelona can be reached directly via /about/Barcelona. The behavior of /about, when given an about value, is exactly like that of /objects when given an object id. For more information, see the API docs at http://api.fluidinfo.com/. Many thanks to Holger Dürer for suggesting /about.
It is now possible to send a checksum of a payload to Fluidinfo via the Content-MD5 header. Fluidinfo will attempt to validate the checksum with the payload and return a 412 (Precondition failed) error in the case of a mismatch. Please see RFC1864 and RFC2616 (Section 14.15).
Daniel A. Nagy reported that his browser was appending ;charset=utf-8 to the Content-type header on his tag value PUT requests with primitive value types. I.e., he’d put application/vnd.fluiddb.value+json in the request Content-type header and his browser would change that to application/vnd.fluiddb.value+json; charset=utf-8, causing Fluidinfo to treat the value as opaque. After some discussion on the #Fluidinfo channel on irc.freenode.net it was decided that Fluidinfo should ignore anything following an initial application/vnd.fluiddb.value+json in Content-type headers. Other Content-type header values will be stored and returned as-is, as usual. Thanks Daniel.
The fix results in a small improvement: the Content-type returned in a GET on an opaque type will be identical in case to the one originally given in the PUT. Formerly, all content types were converted to lower case, but there is no reason for Fluidinfo to alter what it is given.
All HEAD requests for tag values were receiving a Content-Length header containing 0. This has been fixed. Thanks to Rooslan S. Khayrov for pointing this out.
Flash and Silverlight clients request a file called crossdomain.xml which lets them access resources from multiple domains. This is now supported. Thanks to Ross Jempson for the suggestion and testing.
When an existing tag value was changed on an object and the new value had the same type but the request came from a different user than the one who had set the original value, we were returning a 500 (Internal server error) error. This is now fixed.
To reduce internal complexity, and because the Fluidinfo API is expected to be very stable, API version numbers sent in HTTP requests are no longer supported. If you send a request containing a version number, you will now receive a 404 (Not Found).
This release mainly contains internal changes to Fluidinfo, which are not visible to API users. There are no backwards incompatible changes. Changes visible to HTTP API users are the following:
We were not cleanly handling the processing of requests that sent a non-existent username in the credentials. This now results in a 401 (Unauthorized).
We were not doing general handling of the Accept header on requests that return their results in a JSON dictionary payload. In particular, sending */* was getting a 400 (Bad request) error, as reported by Nicholas Tollervey.
We were not doing thorough checking of the types sent for method arguments passed in a JSON dictionary. For example, passing a JSON null value as the description of a new tag would produce a 500 (Internal server error). This has been fixed - we now check the types of all arguments in all JSON dict payloads in all requests and responses.
Note: This change only affects PUT and GET of tag values.
Old behavior: We were using an optional format argument to allow tag values to be set and retrieved in a JSON dictionary. The way we were doing it proved confusing to almost everyone.
New behavior: The format argument is now gone. The caller simply uses Content-Type header to describe the payload, and the special content-type value application/vnd.fluiddb.value+json can be used to send / receive primitive Fluidinfo values (e.g., boolean, int, etc) as JSON. On a GET you may (optionally) indicate what types are acceptable using an Accept header.
What you need to change: Anywhere you were using a format argument, and anywhere you were making a JSON dictionary with a value key.
What you do not need to change: the general sending of arguments to methods in JSON dictionaries or receiving method results in a JSON dictionary. This change only affects tag values, i.e., PUT and GET methods on /objects/ns1/ns2/tag.
Thanks to Holger Dürer for pushing us to reconsider and simplify this behavior.
We have changed how Fluidinfo responds when an error occurs.
Old behavior: We used to send a JSON dictionary payload with an errorClass key containing the specific class of error. This seemed too heavyweight and it also required the application to have a JSON parser.
New behavior: We now send a X-FluidDB-Error-Class HTTP header. This contains the same value as was being sent in the JSON errorClass key. We also send a X-FluidDB-Request-Id header to help us locate specifics of requests. Details.
It was formerly not possible to use an HTTP header of Content-type: "application/json; charset=utf-8" when sending a JSON payload with an about string in creating a new object. This is fixed. Reported by Emanuel Carnevale.
Although it was possible to set a string tag value with text/plain content type, using a charset specifier did not work. This is fixed. Reported by Holger Dürer.
When sending methods arguments in a JSON dictionary payload, the payload was always required - even if all its fields were optional and you didn’t need any of them. This was most obvious in the case of POST on /objects when no about value was needed. This has been fixed: the empty JSON dictionary payload is no longer required.
Fluidinfo used to return a 500 (Internal server error) when the caller tried to add a tag to an object id that didn’t exist. This has been fixed. Reported by Nicholas Radcliffe.
You can now send (PUT) a Boolean and null tag values and GET the value back. These were formerly causing a 500 (Internal server error). Reported by Nicholas Radcliffe.
Some invalid queries that could not be parsed were causing a 500 (Internal server error).
You no longer need to send a JSON payload when doing a GET request on /objects/ID. That was a poor design decision; in fact some HTTP libraries (e.g., .NET) don’t even provide for sending a payload with a GET.
It is now possible to use periods and colons in namespace and tag names. Hyphen and underscore are also still available, of course, as well as letters and digits.