Cool Tools In the Developers Toolbox - getMetadata API
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Australian National Data Service (ANDS)
A spotlight on the ANDS Developer Tool Box - getMetadata API A brief introduction to the powerful open source getMetadata API, which can be used in your applications to perform complex search queries against the ANDS Collection Registry. It differs to the other Collection Registry APIs in that it returns a JSON representation of the metadata fields and not the original RIF-CS XML."
 Thanks everybody for turning up. Joel Ben here, business analyst in the services team. The next service is quite similar to the GetRoofCS service. It differs in the way that it actually returns data formatted in JSON, which is another structured format. And by doing that, they can actually pick and choose the fields that they want to return in their queries. And it makes more lightweight basically, so they can optimize the performance of their applications. They may just want a title and a brief description, let's say, for a search results or something, instead of pulling back the whole RooFCS chunk for each record. The service itself allows simple spatial searches as well. And they can obviously do searches across the whole index that we have in Research Data Australia. So again, just the address for researchdataaustralia.a. And that all that are you for slash developers. The web services themselves, they're not as pretty because there's no real fancy front end to them. There are little explanation diagrams for each, I think nearly all of the services that we have, just showing sort of how they work. There's obviously the description and the use cases for each of the services, how people might want to implement them and the use points about them. As you can see here before you start, the one thing to note about the services themselves is that any developer that wants to use them actually has to register for a API key that they pass when they call them the services. And that's just the way of us knowing and identifying who's actually using the services. You don't have to be a user with a log onto the registry. You can just click the link and it'll take you to a publicly accessible page where you fill out the organization, the contact email, and why you want to use the API key. And you click register and it will run down then generate your key to pass with the service calls. In much the same way as the widgets, we have tables containing all the parameters that can be passed to the services themselves. And again, the developers will understand that and if they don't, they can get in contact via the community forum. There's a couple of, in some of the services, they're a little bit tricky. There's sort of some sort of FAQs or common questions about the services just to help out. And a couple of example uses of working. It's the working service calls. And that's pretty much all I've got.
 Thanks everybody for turning up.  Joel Ben here, business analyst in the services team.  The next service is quite similar to the GetRoofCS service.  It differs in the way that it actually returns data formatted in JSON,  which is another structured format.  And by doing that, they can actually pick and choose the fields that they want to  return in their queries.  And it makes more lightweight basically,  so they can optimize the performance of their applications.  They may just want a title and a brief description, let's say,  for a search results or something,  instead of pulling back the whole RooFCS chunk for each record.  The service itself allows simple spatial searches as well.  And they can obviously do searches across the whole index  that we have in Research Data Australia.  So again, just the address for researchdataaustralia.a.  And that all that are you for slash developers.  The web services themselves, they're not as pretty because there's  no real fancy front end to them.  There are little explanation diagrams for each,  I think nearly all of the services that we have,  just showing sort of how they work.  There's obviously the description and the use cases for each of the services,  how people might want to implement them and the use points about them.  As you can see here before you start,  the one thing to note about the services themselves is that  any developer that wants to use them actually has to register for a  API key that they pass when they call them the services.  And that's just the way of us knowing and identifying who's actually using the services.  You don't have to be a user with a log onto the registry.  You can just click the link and it'll take you to a publicly accessible page  where you fill out the organization, the contact email,  and why you want to use the API key.  And you click register and it will run down then generate your key  to pass with the service calls.  In much the same way as the widgets, we have tables containing all the parameters that can be passed  to the services themselves.  And again, the developers will understand that and if they don't,  they can get in contact via the community forum.  There's a couple of, in some of the services, they're a little bit tricky.  There's sort of some sort of FAQs or common questions about the services just to help out.  And a couple of example uses of working.  It's the working service calls.  And that's pretty much all I've got.
getMetadata_API_-_Cool_Tools_in_the_Developers_Toolbox_VgsSrzGme4o_1_0_47.png getMetadata_API_-_Cool_Tools_in_the_Developers_Toolbox_VgsSrzGme4o_1_48_1175.png getMetadata_API_-_Cool_Tools_in_the_Developers_Toolbox_VgsSrzGme4o_1_1176_3716.png