Re: Første notater fra testing av tjenestegrensesnitt-API hos Evry

Thomas Sødring thomas.sodring at oslomet.no
Sat Mar 2 18:10:41 CET 2019


Hei,

Dette er spennende! Bra jobbet Petter! Fint at Evry deler en instans slik at det er mulig å verifisere implementasjonen deres opp mot standarden. Evry er, så vidt jeg vet, de eneste av leverandørene som implementerer tjenestegrensesnittet. Men jeg ser at Visma og Documaster kommenterer tjenestegrensesnittet, men det er usikkert hvorvidt de har implementert den.

Det du påpeker Petter kan være noe av det vi møtte på i nikita. Jeg prøvde først å bruke en standardisert hateoas bibliotek og da fikk vi flere attributter og biblioteket brukte andre måte å beskrive JSON-objektene. Jeg tror disse bibliotekene standardiserer serialisation av objekter på hver sin måte og ikke i henhold til en standard. I nikita prosjektet valgte vi å bygge vår egen Noark-serialiser for å kunne sikre kontroll over objektene når de skal returneres til klienten.

Jeg tok et kjapp søk for det JSON formatet som du viser til og det kommer opp treff på:

http://rel.kxml.no/noark5/v4/api/arkivstruktur/ny-registrering/
http://rel.kxml.no/noark5/v4/api/arkivstruktur/ny-mappe/

Så det virker som om det er flere beskrivelser som er ute og går! Fint at du setter fokus på dette med standardisering Petter. En av de verste utfallene når tjenestegrensesnittet er ferdig spesifisert er at det blir flere tolkninger. Varierende tolkninger og ingen mulighet til å kontrollere implementasjonen er anti-standardisering!

Videre søk gir følgende:

  https://github.com/otto-de/edison-hal

Det er et prosjekt som sier det er en implementasjon av HAL-hateoas som er spesifisert her:

  https://tools.ietf.org/html/draft-kelly-json-hal-08#section-5

men den lenken inneholder ingen beskrivelse for templatedSpecified som finnes i Evry sin implementasjon og noen eksempler på rel.kxml.no.

Petter delte følgende lenke med meg som et eksempel på  spesifisering av påloggingsmekanismen:

  https://oidc.difi.no/idporten-oidc-provider/.well-known/openid-configuration

Vi må prøve å få til noe lignende i nikita og i tjenestegrensesnittet- Et annet beskrivelse er her:

  https://auth0.com/docs/protocols/oidc/openid-connect-discovery

Takk Omar og Evry for at dere er med og implementerer tjenestegrensesnittet på en åpen måte. Når to implementasjoner av standarden finnes, med en kontroll mekanisme for verifisering så har vi kanskje med en standard å gjøre. Alt annet er bare synsing.

 - Thomas

On 3/1/19 2:41 PM, Petter Reinholdtsen wrote:


Hei Omar, som avtalt, her er mine foreløbige notater etter å ha testet
API-et jeg fikk tilgang til.  Det ser ut til at dere, som du nevnte, har
en god del å fikse for å være i tråd med både spesifikasjon beta 1 og
siste oppdaterte fra github.

Cc til nikita-epostlisten, slik at de andre i prosjektet blir
oppmerksomme på hvor Evry og Nikita så langt har implementert ting
forskjellig.  Får ikke testet noe mer med mitt testsystem så lenge ingen
JSON-resultater inneholder { "_links" : ... }.


Arbeidsdokument av Petter Reinholdtsen, sist oppdatert 2019-03-01.

Tester oppkobling til
https://publicecm.elements-ecm.no/nCore/api?database=EXTERNAL_TEST&externalSystemName=Noark5Services

Det var uklart hvordan innlogging skal gjøres, og det gjøres ikke som i
Nikita.  Det må avklares i API-spec og implementeres likt hos Evry og
Nikita for at klienter skal bli leverandøruavhengige og kunne koble
seg til et hvilken som helst implementasjon av tjenestegrensesnittet.

Relasjonslenker på toppnivå har skrivefeil, doble skråstrek skulle
vært enkle.  Det mangler også avsluttende skråstrek. Det betyr at
"http://rel.kxml.no/noark5/v4/api//arkivstruktur"<http://rel.kxml.no/noark5/v4/api//arkivstruktur> skal være
"http://rel.kxml.no/noark5/v4/api/arkivstruktur/"<http://rel.kxml.no/noark5/v4/api/arkivstruktur/>.  Se også
<URL: https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues/15 >.

Relasjonslenker på toppnivå mangler _links og har feil format,
dvs. det ser slikt ut:

  [ { "rel": ... } ]

Det skulle sett slik ut, beskrevet i kapittel 6 i
tjenestegrensesnitt-spesifikasjonen:

  { "_links": [ { "rel": ... } ] }

Hver enkelt relasjon har felt som ikke trengs / skal være med.  Ser
slik ut:

  {
    "rel": "http://rel.kxml.no/noark5/v4/api//arkivstruktur"<http://rel.kxml.no/noark5/v4/api//arkivstruktur>,
    "href": "https://publicecm.elements-ecm.no/nCore/api/arkivstruktur"<https://publicecm.elements-ecm.no/nCore/api/arkivstruktur>,
    "templatedSpecified": false,
    "type": null,
    "deprecation": null,
    "name": null,
    "title": null
  },

Feltene "type", "deprecation", "name" og "title" hører ikke hjemme
her, så vidt jeg vet.  Feltet "templatedSpecified" trengs ikke, det er
valgfritt.  Se også
<URL: https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues/16 >
for en mangelmelding relatert til det første feltet og hvordan
speifikasjonen nå gjør det klart at feltet ikke skal være med hvis det
er 'false'.

Det ser ut til at href-URLene mangler
"?database=EXTERNAL_TEST&externalSystemName=Noark5Services" som ser ut
til å trengs for å få tilgang til API-et.  Det gjør at URL-ene ikke
kan brukes til å bevege seg rundt i API-et, og er så vidt jeg forstår
i strid med HATEOAS.

Her er testkjøring med runtest etter å implementere støtte for 'Basic'
autentisering selv om HTTP-forespørsler ikke inneholder
WWW-Authentication slik RFC 7617 anbefaler:

failure: level 0 CORS - HTTP OPTTIONS request not working
xfailure: level 0 API should support support Basic access authentication
failure: level 0 XML - incorrect Content-Type for base: text/html; charset=utf-8
success: level 0 JSON - found base
failure: level 0 JSON - incorrect content-type for base: text/html; charset=utf-8
success: GET . worked with code 200
failure: GET header should include Allow for .
failure: MIME type text/html; charset=utf-8 should be application/vnd.noark5-v4+json for url .
failure: OPTIONS failed for URL .: HTTP Error 405: Method Not Allowed (HTTP Error 405: Method Not Allowed)
error: Unable to find login relation, falling back to Basic auth
failure: unable to log in, operating in read only mode: Unable to log in
failure: unable to create a new fonds, no http://rel.kxml.no/noark5/v4/api/arkivstruktur/ny-arkiv/ entry discovered even if logged in
failure: unable to create arkiv with opprettetDato='1997-07-16T19:20+01:00'
failure: unable to create arkiv with opprettetDato='1997-07-16T19:20:30+01:00'
failure: unable to create arkiv with opprettetDato='1997-07-16T19:20:30.45+01:00'
failure: unable to create arkiv with opprettetDato='2012-10-10T15:00:00'
failure: unable to create arkiv with opprettetDato='2014-11-22T15:15:02.956+01:00'
xfailure: unable to create arkiv with opprettetDato='1997'
xfailure: unable to create arkiv with opprettetDato='1997-07'
xfailure: unable to create arkiv with opprettetDato='1997-07-16'
xfailure: unable to create arkiv with opprettetDato='1865-02-13T00:00:00Z'
failure: not logged in, unable to test creation
2 successes, 14 failures, 5 expected failures



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.nuug.no/pipermail/nikita-noark/attachments/20190302/1cfea357/attachment-0001.htm 


More information about the nikita-noark mailing list