A web service enables machine-to-machine communication by providing a standardized way to use interfaces from remote systems.
Therefore, data is exchanged and functions are called up on remote computers. Each web service has a Uniform Resource Identifier (URI) which uniquely identifies it.
Furthermore, each web service has an interface description, the so called web service API (application programming interface) which describes all provided functionalities and defines how to interact with the web service.
Web services can be implemented in different ways. The most common are:
REST-APIs (Representational State Transfer) and
SOAP-Services (Simple Object Access Protocol).
The DACHSER web services follow the REST paradigm as it offers more flexibility to the web service consumer. Additionally in contrast to SOAP, all request parameters are contained in the query or in the request header section.
The web service response is an optimized JSON structure without any overhead.
It is possible to test an API from this Developer Portal.
When looking at the details of an API you will see a table of the operations contained in the API. This will show what method they are (GET, POST, PUT, DELETE, PATCH, HEAD or OPTIONS) and what path the Resource uses.
If you click on the Resource you will see more information about it, what parameters it might take, what it returns, what possible return codes it might use and what they mean.
There is also a 'CALL OPERATION' button which enables you to try the Resource out direct from the Developer Portal.
If the API requires a client ID or a client secret for identification then you can specify these at the top of the 'Try' section.
A plan is collection of API resources or subsets of resources from one or more API. A plan can contain a mixture of HTTP GET, PUT, POST, and DELETE verbs from different APIs or it can contain all the GET verbs from various APIs. A plan can have a common rate limit for all the resources or each resource can have a different rate limit. Rate limits specify how many requests an application is allowed to make during a specified time interval.
Use this Developer Portal to browse the different plans that are available to you and select a plan that is most suitable for your requirements. Some plans have restricted access that you must request access to use. When you submit your request, the organization is notified, the API administrator assesses your request and they might contact you for more details. Other plans are available to use straight away.
In computing, the robustness principle is a design guideline for software:
Be conservative in what you do, be liberal in what you accept from others
The principle is also known as Postel's law, after Jon Postel, who wrote in an early specification of TCP In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
(extract from https://en.wikipedia.org/wiki/Robustness_principle)
When you add an application you are provided with a client ID and client secret for the application. You must supply the client ID when you call an API that requires you to identify your application by using a client ID, or a client ID and client secret.
Once logged, to register an application click on 'MY SUBSCRIPTIONS' in the main menu and then click on the '+ CREATE NEW APP' link. Once you have provided an application name, description, etc you will be shown your application client ID and client secret.
Make a note of your client secret because it is only displayed once. You must supply the client secret when you call an API that requires you to identify your application by using a Client ID and Client secret.