URL

[JonathanRowell]

After implementing DAIA in Bibdia for SLB Potsdam/KOBV I thought I'd have a look at the next interface PAIA. Why on earth does the specfication insist on explicit URLs? And why is the patron identifier also in the URL? First the explicit URLs mean I'd have to map /core internally into a URL to Bibdia. The site CANNOT use /core for anything else but PAIA. Secondly why is the patron identifier plain for all to see in the URL? Once again I'd have to rewrite this into a more conventional URL which, for example, DAIA uses. In DAIA the URL is not specified, just the parameters to it. OAI follows a similar procedure, so does NCIP via HTTPS. And why the patron ID is part of the URL instead of just simply a parameter (and then in a POST body) is beyond me, since the patron is actually a parameter and not a resource identifier. The last part of the URL is similarly a verb.

[nichtich]

Thanks for feedback. You could also another base URL e.g. https://mylibrary.org/user/ for PAIA core and https://myidprovider.com/ for PAIA auth. Should the documentation be more clear about this possibility?

Putting patron identifiers in the URL was motivated by REST and this way each patron account has an URI as well.

[JonathanRowell]

I was actually thinking along the lines of DAIA, namely //my.server.myorg/mydir/myurl.myscript?verb=...&patron=...&so%20and%20so%20forth. Also posting the same sort of parameters with urlencoding or even as XML or JSON with the appropiate content type.

REST doesn't mean squashing all the "parameters" into the URL but producing data instead of rendering the data as content. Elastic Search calls itself a REST database, although you post and receive somewhat complex JSON objects.

[nichtich]

I hope to have clarified this question, so I'm closing this issue.