Functionality added : conformance level description

Thomas Sødring tsodring at gmail.com
Thu Dec 1 09:24:22 CET 2016


Folks,

I'm back developing as I have had a few days between the end of the
teaching semester and exam correction time. I thought I'd prioritise
what Petter was asking for and that is the top level description of
functionality the core supports and where the associated apis are located.

curl -i --header "Accept:application/vnd.noark5-v4+json" -X GET
http://127.0.0.1:8092/noark5v4

will now return the following:

{
  "_links" : [ {
    "href" : "http://127.0.0.1:8092/noark5v4/hateoas-api/arkivstruktur",
    "rel" : "http://rel.kxml.no/noark5/v4/api/arkivstruktur"
  }, {
    "href" : "http://127.0.0.1:8092/noark5v4/hateoas-api/sakarkiv",
    "rel" : "http://rel.kxml.no/noark5/v4/api/sakarkiv"
  }, {
    "href" : "http://127.0.0.1:8092/noark5v4/api",
    "rel" : "http://nikita.arkivlab.no/noark5/v4/api"
  }, {
    "href" : "http://127.0.0.1:8092/noark5v4/gui",
    "rel" : "http://nikita.arkivlab.no/noark5/v4/gui"
  } ]
}

The first two are the official Noark 5 api interfaces that we must
support, the final two are my own apis that I want to support. We will
probably see a few more official api descriptions in the future.
byggesak and masseimport are two that I think will be on the horison soon.

It makes sense that this description is located straight of the
contextPath (/noark5v4)

Please note that going forward you must specify that you only accept
application/vnd.noark5-v4+json on the client. The core will only produce
"application/vnd.noark5-v4+json". application/json will now return a 406
HTTPMediaTypeNotAcceptable as should be verifiable with the following
curl command:

curl -i --header "Accept:application/json" -X GET
http://127.0.0.1:8092/noark5v4

I have pushed this through today and it should be running without any
problems. Let me know if there are any problems.

The next thing I want to go back to is to working with the fonds
(no:arkiv) object. I need to ensure that you have to have the correct
role (RECORD_MANAGER) to do anything at this level in the archive
hierarchy. There are also a few issues about what the fonds can be
linked to. e.g. a subfonds and a series cannot be linked the same fonds
object.

There is still a little bit of exploration to be done on the
implementation of spring security and ownership assignment including
allowable CRUD operations. That's about a week of work to land it properly.

I also have to do a bit of work on the creation of HATEAOS objects that
should include functionality description on objects being returned. An
example is that if we retrieve a fonds object, I should also include
links showing what the current user can do with that fonds object e.g.
close it, delete etc. I have not come up with a strategy to handle that
yet, but I learned a lot dealing with conformitylevel descriptions,
including writing my own serializer.

I also need to get control of the testing framework to make sure that it
moves forward with development.

There will probably be 2 or 3 small updates between now and Christmas
where I finalise fonds functionality and get the security mechanism
properly into place.

 - Tom


More information about the nikita-noark mailing list