Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Warning

NOTE: This page was copied from the old MoinMoin wiki and contains many

...

Panel

markup artifacts and incorrect translations. Consult the
the original page preserved here if you need precise
answers about URI syntax, identifiers, etc.

...

This page describes a simple but comprehensive network interface .
that was developed as part of the CWSpace project.
It was designed to be complete enough for most programmatic uses of
the DSpace API, particularly submitting and extracting archived materials
as packages or byte streams.

It is documented here, and the source code made available on
Downloads and Clients in the
hope that it will be generally useful to the DSpace community.

See Also

Downloads and Clients for a sample
implementation (unstable) and a pre-built test client.

This page is more of a design
specification than a tutorial manual. For more documentation,
see the WebDAV page
(WebDAV protocol and client libraries in Java and C that can be used with
the LNI).

Requirements

Since it has been difficult to elicit a coherent set of requirements for
this project, one of our primary goals is to make the interface easy to
extend, in the hope of meeting many as-yet-unknown requirements.

Also, please help by responding to this page and adding your requirements and
anticipated usage here.

Specific Requirements

...

This network interface borrows the data model of the
WebDAV protocol – the simplest case without locking
or versioning. WebDAV is a proven and robust protocol that was designed for a
similar purpose: accessing and modifying resources and their metadata
over a network.

It is actually a full, though minimal, WebDAV server implementation,
although it also supports SOAP RPC alternative calls for all the DAV
methods which are not part of standard HTTP.

The SOAP alternatives are required by the CWSpace
project, for which this interface was created. Since SOAP is
not capable of the bulk data transfers required to ingest and disseminate
content packages, some operations are still implemented on top of HTTP.
The implementation is structured so it is not difficult to maintain
both the hybrid SOAP/HTTP and pure HTTP-WebDAV interfaces.

...

Adopting the WebDAV data model lets us borrow its XML schemas and
leverage its proven architecture. The WebDAV interface lets many
existing WebDAV clients applications interact with DSpace to some
degree. There are many WebDAV clients available as software libraries
on various platforms, which makes it easy to integrate other applications
with DSpace through WebDAV.

The hybrid of SOAP RPC and HTTP satisfies a CWSpace requirement to use
SOAP wherever it is practical.
We employ HTTP GET and PUT
for bulk data transfers
to avoid the inefficiency and implementation limits of processing large
bitstreams and content packages as base64-encoded components in SOAP message.

While the SOAP attachment protocol would appear be a more obvious choice
for bulk data transfers
than HTTP, it lacks maturity and widespread implementations. SOAP
attachments also require cumbersome, inefficient and poorly-standardized
MIME encoding.

DSpace Network Interface – Specification

...

The LNI lets you refer to
DSpace objects (such as Items, Collections, etc) as
resources, in the HTTP sense.
There is a simple and deterministic, though intentionally opaque,
mapping of DSpace objects to resource URIs.

Note

...

Do not conflate the WebDAV resource URIs with "URLs" to be

...

used in an interactive Web browser. The LNI's resource URIs are not to

...

be used interactively, and should never be archived or saved for later

...

reference. Most of the URIs (with the notable exception of

...

lookup)

...

used with the LNI are obtained from the LNI itself, and are not

...

guaranteed to be stable over the long term.

About the "prefix" Prefix is the initial URL path at which
the LNI service is "mounted" on its Web server. Since the LNI is intended
to be run out of a Java Servlet container such as Tomcat, possibly
the same one running other DSpace services (e.g. the Web UI), it
will probably be mounted under a separate initial path to distinguish
its requests from those bound for other servlets. For example,
on a server host `"library.uni.edu"`, if the LNI is mounted at `/dspace/dav`,
the complete prefix is `http://library.uni.edu/dspace/dav`.

...