Create spec for service API v2

[emanueldima]

Currently planned are multiple inputs and for each input a more detailed description:

• original link or PID,
• link to switchboard copy of the data (to bypass cors issues),
• mediatype?, language?, etc.

A general reorganization of the tasks/endopoints is needed: A tool should have multiple tasks with possibly different endpoints and parameters. For example Weblicht should be described by a single file with multiple entries for tasks and parameters, not by multiple files, each one for one task.

Other questions/requirements:

• Should we use POST instead of GET? GET allows us to preserve the query after Shibboleth logins, we don't know if POSTs will behave the same.
• Accepting any language should be more explicit (currently we accept "generic" like a language identifier, see What should the absence of language specification for a tool mean? #48)
• We can provide 2 or 3 options for sending data to services, and allow the service configuration to specify their ideal method (e.g. GET with link, POST with link, POST with full data).

[dietervu]

FTR (requires further investigation): POST might cause issues with shibbolized services, while URL-encoded GET parameters should be passed through transparently.

[proycon]

I assume this issue entails a redesign/extension of the registry format. You may want to look into the related work done in CLAM and also in the OpenAPI Initiative (formerly known as swagger), both are a lot more expressive than the current switchboard registry and support things like multiple inputs (and full parametrisation, but you may not want to go that far for the switchboard).

For generic tool metadata, I'd also recommend taking a look at codemeta, which maps various metadata schemes to a common vocabulary.

[emanueldima]

done now, documented in clarin-eric/switchboard-doc#15