erasmus-without-paper / ewp-specs-api-institutions

Specifications of EWP's Institutions API.
MIT License
0 stars 0 forks source link

Institutions API

Summary

This document describes the Institutions API. Once implemented by the host, it allows external clients to retrieve general information on institutions either covered, or otherwise known, by this host. This information includes things like address, logo image and key contact persons.

"Covered" vs "known"

Initially, this API was supposed to work only with hei_ids covered by the server's EWP Host. In other words, implementers were required to return information only on "their own" HEIs. Later, however, it turned out that in some cases, it would also be very useful if the server could provide some (very basic) information on other known HEIs too.

Therefore, it is now RECOMMENDED for server implementers to also provide some basic information on all external institutions which they refer to (by their SCHAC IDs) in other EWP APIs. It doesn't have to be much information though (most often, just the name will be enough).

Request method

Request parameters

Parameters MUST be provided in the regular application/x-www-form-urlencoded format.

hei_id (repeatable, required)

A list of institution identifiers (no more than <max-hei-ids> items) - IDs of HEIs the client wants to retrieve information on.

This parameter is repeatable, so the request MAY contain multiple occurrences of it. The server is REQUIRED to process all of them.

Server implementers provide their own chosen value of <max-hei-ids> via their manifest entry (see manifest-entry.xsd). Clients SHOULD parse this value (or assume its equal to 1).

Clients may retrieve proper HEI identifiers from other EWP APIs (most often, the Registry Service). Servers MUST be able to accept all HEI IDs declared in their manifest files, and all HEI IDs which they refer to in other EWP APIs.

Security

This version of this API uses standard EWP Authentication and Security, Version 2. Server implementers choose which security methods they support by declaring them in their Manifest API entry.

This API provides data which is also usually accessible to the anonymous public by other channels. It is RECOMMENDED for server implementers to not be overly strict on security methods they require (i.e. it is RECOMMENDED to not require extra layers of encryption in requests and responses - TLS seems more than enough). Server implementers MAY also consider allowing this API to be accessed by anonymous clients.

Handling of invalid parameters

Response

Servers MUST respond with a valid XML document described by the response.xsd schema. See the schema annotations for further information.

Related data model entities