I've decided that mapguide-rest has enough features to lock in the 1.0 version number.
Here's what's new in this release.
Cleaner JSON responses
If you've used JSON output from mapguide-rest or MapGuide proper, you'll notice that the JSON is ugly and cumbersome to use:
- Every JSON property is an array
- All property values are strings
The main reason this JSON is so ugly is because of the way that XML is converted to JSON. The conversion process knows nothing about the content model of the XML document it is trying to convert, so as a lowest-common-denominator solution, it forces all converted XML elements to JSON array properties and all XML text elements as string values. While this allows for rudimentary usage by client applications, it's not a pleasant experience.
For this release, we've set out to solve this problem. The JSON produced which would've looked like this:
Now looks like this:
How did we achieve this? Simply put, we now maintain a hard-coded list of known XML element paths (compiled from all the MapGuide XML schemas) and make note of:
- Which paths must always be processed as a JSON array
- Which paths have values whose data type is not a string
With this list, we now know which XML elements need to be converted to JSON arrays and which elements need to be converted to JSON property values, and the proper data type to convert such values to.
The end result is that the new JSON responses are much more natural and intuitive to work with. Not to mention these new JSON responses are smaller than their previous counterparts. Those extra [ and " characters do add up.
This is a PHP-level solution. With this release, all JSON conversion/output is now handled by mapguide-rest. While slower than doing it natively in MapGuide, it gives us more usable JSON structures and this increased usability is worth it for the slower performance.
As for the old JSON response structure, that is going away in mapguide-rest. This new structure will be used for all APIs in mapguide-rest that return JSON. If you want the old JSON structured responses, you'll have to go back to the mapagent.
In one particular case, we eschew the convert-to-JSON-from-XML approach and define a new dedicated JSON response format.
Ever tried to describe the schema of a Feature Source? This is the XML response:
Have you seen the JSON version of this monstrosity?
How on earth would any sane person know how to use this response in their applications? Yeah me neither.
So for schemas and class definitions that are returned as JSON, we introduce a more cleaner and intuitive JSON format
Isn't that a more intuitive and self-explanatory JSON response?
This new response structure is only applicable for JSON schemas and class definitions. The XML version of these schemas and class definitions will still be its same ugly and verbose self. From my perspective, XML is the "legacy" response format in mapguide-rest. JSON is the preferred response format for any client application and so we should strive to make consuming such data in this format as simple and clean as possible. With this release, hopefully we've achieved that objective.
While we're still on the subject of JSON, for certain REST APIs that previously accepted XML request bodies, such APIs now support JSON-equivalent request bodies. For example, consider this route to set resource content:
POST /rest/library/{resourcePath}/content.xml
To set resource content, you'd make a POST request to this route and include the resource XML as part of the request body.
You can now set the same resource content via its JSON representation
POST /rest/library/{resourcePath}/content.json
By making a POST request to this route and include the equivalent JSON as part of the request body. Because our JSON formats now structurally follow their XML counterparts, knowing what JSON to construct should be easy to figure out. On the server-side such JSON bodies will be converted back to its XML counterpart before passing down to the underlying MapGuide APIs (because sadly XML is still the canonical format for storage and data transfer throughout the official MapGuide APIs)
Authoring APIs for restcfg.json files
We've added a set of new APIs in the data publishing framework to allow for restcfg.json and any supporting files to be uploaded from a mapguide-rest client without needing physical access to the directory where the restcfg.json files are stored.
These authoring APIs allow you to:
- Upload a restcfg.json file to a desired subdirectory within mapguide-rest based on the given URI part
- Upload any supporting files to the subdirectory mapped to the given URI part
- Delete any restcfg.json configuration
- Delete any supporting file of a restcfg.json configuration
Because URI parts are mapped to physical subdirectories within a mapguide-rest installation, there could be a opportunities for malicious activity without proper security precautions. To this effect, we do the following:
- Such APIs require Administrator or Author-level roles to be assigned to the authenticated user. The MapGuide Anonymous users will not have such roles, and thus any attempt at accessing these APIs will be denied.
- Any URI parts and filename parameters are sanitized to strip off any semblance of relative paths and any other path navigation tricks that would cause mapguide-rest to save/delete a file or directory outside of its installation directory.
You can find out how to use these new APIs in the
built-in interactive API reference.
API additions and cleanups
APIs that previously returned simple primitive values now return a XML or JSON boxed version of that value. Simply put, if an API returned a boolean value like this:
true
It will now return a boxed value, which looks like this for XML:
And looks like this for JSON:
{ "PrimitiveValue": { "Type": "Boolean", "Value": true } }
While this looks more verbose, it is simply to provide a consistent developer experience. If you have been expecting XML or JSON responses for 99% of the APIs, why make an exception for this 1% of APIs that return basic primitive values? They should be XML or JSON respectively as well and in order for that to happen, we have to box such values.
In addition many new APIs have been added to cover missing pieces and loose ends in our REST API:
- Creating Feature Sources
- Setting and deleting resource data items
- Listing Long Transactions of a supported Feature Source
- Getting the coordinate system base library
- Validating Coordinate System WKT
- Converting Coordinate System WKT to EPSG codes
- Testing the connectivity of a Feature Source
- Enumerating unmanaged (aliased) data
- Getting site information status/statistics
- DescribeSchema with class name hint
- Setting content and header of any resource in a single request
- Fusion layout authoring support APIs
- Interrogating and setting the edit-ability of a Feature Source with the REST API
You can find out how to use these new APIs in the
built-in interactive API reference.
(Geo)JSON CRUD support in restcfg.json
The data publishing framework now supports CRUD for JSON representations. The JSON representation is much more simpler and compact in its request payloads. The requests to create, update and delete features are structurally the same as the XML one (using the same XML-to-JSON pattern for most of our JSON data structures)
The existing Editable Properties example has been modified to use the JSON representation instead of the XML one. For doing CRUD through the data publishing framework, I'm sure you'll find it much easier to work with this JSON representation than the XML one.
Customizable HTML representation
The HTML representation for features are now customizable and localizable as the previous bits of hardcoded HTML that were rendered out by the HTML renderer, have all been extracted out into Smarty templates, where you can customize the HTML to your own liking.
MapGuide 3.0 support
This release of mapguide-rest supports new features introduced in
MapGuide Open Source 3.0.
- Your tile service routes can also work with Tile Set Definitions
- XYZ tile requests will pass through to the MapGuide API on a MGOS 3.0 install
- Runtime Map responses use the v3.0.0 response schema
Other changes
From now to the final 1.0 release of mapguide-rest, it will be nothing but bug fixes and (really) minor enhancements.
After 1.0
as I've somewhat hinted, if mapguide-rest as a project should have a continued evolution, I strongly believe it should be on the
ASP.net 5.0 platform. Given ASP.net 5.0 won't see light for many more months, I'll have plenty of time to play and experiment with many ideas that are possible with ASP.net 5.0
Posts
