Web service design standards¶

• Table of contents
• Web service design standards
  • Web services: basic rules
  • Web service request format
  • Web service response format
  • Reporting errors by web services
  • Authentication
  • API versions

Web services: basic rules¶

• We will expect requests in POST, not GET. We will not design URLs to communicate request parameters. The only exception will be in "deep URL" cases where we need to supply a link or button somewhere which will take the user directly to a specific object instance within a module, for instance, the edit screen of a specific voucher within the FA module. In such cases, we can append the object ID to the URL, and use GET.
• All JSON data structures will have member names in full lowercase. No mixed-case will be used.
• We will use only HTTPS for all web services traffic. Calls must fail if HTTP is attempted.
• HTTP response codes should not be examined by the caller to decide success or failure of the call -- any HTTP code in the range 200 to 299 should be accepted as success. HTTP protocol response codes are supposed to indicate protocol level and basic transport level issues -- not application level success or failure.

Web service request format¶

• Example

{
    "ver": 1,
    "uid": "xpq1234",
    "authtoken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ",
    "data": {
        "goal_id": 23
    }
}

• ver is the API version to be used. See the section on "API version" below.
• uid is user id for user-oriented applications. It will be an opaque one-word string. The field may be called boxid for embedded applications where IoT boxes invoke web services. It may be sysid or serverid where there are no human users, but servers invoke web services. For some web service calls it will be optional, e.g. for operations which do not need any user identification or box identification.
• authtoken is the (optional) JWT authentication token, which will be one long, opaque string in three sections, separated by periods, as can be seen here. Some web services may not require authenticated access, and for those calls, this field may be dropped. See the section on "Authentication" below.
• data is the request data object. Each web service will define its own data object, with some mandatory and some optional fields.

In some cases, a web service only requires uid or boxid as input. In those cases value of data will be an empty object.

e.g.

{
    "ver": 1,
    "boxid": 1234,
    "data": {}
}

Web service response format¶

A consistent JSON data structure will be returned by the API for success or errors. For successes, the following JSON structure will be returned:

{
    "status": "success",
    "data": {
    /* Application-specific data payload goes here. */
    },
    "messages": [] /* Or optional success message */
}

The contents of data for each web service call is provided in its detailed documentation. Note how the message block is an empty array here. The status attribute will always be returned in every response.

For errors, the following JSON structure will be returned:

{
    "status": "error",
    "data": {},
    "messages": [{
        "code": "code1",
        "msg": "message1"
    }, {
        "code": "code2",
        "msg": "message2"
    }]
}

Note that the data block is empty in case of errors, and the error messages will be listed in message. An example of an error response:

{
    "status": "error",
    "data": {},
    "messages": [{
        "code": "permission_denied",
        "msg": "No permission for the requested operation."
    }, {
        "code": "account_restricted",
        "msg": "The user account is disabled."
    }]
}

The data block is an object, not an array. And the messages array is always an array, never an object.

Reporting errors by web services¶

Each error reported has two parts:

• the error code
• the human readable error message

The code is always going to be one word, always in lower case, with letters, digits, and/or underscore characters.

The code is the real indicator of the type of error, and must be used by the client code. It may handle the error, it may retry the operation, it may branch into a different path in the code, it may select a message to show the end-user, etc, as needed. The error message supplied by the web service is meant for the programmer of the client software to understand and debug the web service call. It is not meant to be used for end-user display.

In multi-lingual user interfaces, the error message must be indexed to the combination of (language, errcode) and the appropriate language-specific error message must be selected from a table and displayed to end-users. The responsibility of designing and selecting meaningful error messages in the correct language lies with the client software. The client software dev team must build error message tables in each supported language. The error message supplied by the web service will always be in English, and may not have appropriate wording to display directly to the end-user. Its audience is the programmer of the client software.

Authentication¶

Typically, the web services layer will need to authenticate clients which are invoking them. If it's a human-user oriented application, then the human will need to be authenticated sometime. If the web services are invoked by devices, then each device will need to be authenticated at least once, maybe periodically, to ensure that the API does not remain completely open to outside access.

Therefore, there will be at least one login() web service in every application, where the client will identify itself.

User-based authentication: The login() call may accept a username and password, or there may be a back-end OTP loop where the user just submits his username and the system sends an OTP to his registered mobile number which is later submitted through a second web service.

Finally, on successful authentication, the web service will return a JWT token to the client. This JWT token will need to be submitted as part of the fixed header fields of all subsequent web services which expect authenticated access.

Device-based authentication: The login() call may be designed to require a unique ID. This ID may be generated from some unique aspects of the device hardware (e.g.

dmidecode | grep relevant-lines | md5sum

on Linux, as a very rough mechanism, or some ROM-embedded unique serial number embedded there by the hardware manufacturer, or some other naturally occurring unique ID like Ethernet MAC address.

This ID will uniquely (we assume) identify one device. The web service will check to see if this device is authorised to access the system, and may do some back-end cross-checks using OTP to some authorised person's mobile phone or some other two-factor authentication. The device may then have to make a second call to submit the second factor for the authentication to complete. Finally, when the web service is satisfied that all is well, it will issue a JWT token to the client. This client will need to be included as part of the fixed header of all subsequent web service requests. All web services which expected authenticated access will first check the validity of the token before processing other parameters. If the token is invalid, the web service will respond with a authtoken_invalid error.

JWT token replacement: All JWT tokens expire, and it is a good idea to let them refresh, for security reasons. When a web service receives an expired token in its request, it will respond immediately with a special error code indicating authtoken_expired without looking at other parameters. What happens next will depend on the application design.

• Token replacement: One approach will be to issue a fresh token in lieu of the old one. There will be a special web service whose only job will be to issue a new token. It will take the old token, check all other fields for validity, check that the internal user tables or device masters still permit this client to continue using the services, and then it will create and send back a new token with a fresh expiry date. The client will receive this new token and will use it henceforth for all accesses. To use this approach, the client code will have to be designed to detect authtoken_expired errors and automatically make this call for generating a fresh token.
• Fresh authentication: For higher security, it may be necessary, specially in user-based applications, to do a full authentication afresh. In this approach, the user will simply be logged out and will be asked to "sign in again". Therefore, whatever was done the first time to authenticate the user or device will now have to be re-done, and manual intervention may be needed at the client end.

API versions¶

Any web service (we will refer to it as "service" here) which is exposed to multiple clients (software systems which send web services requests to our service) will, over time, have to serve old clients and new ones.

Our service will grow in features and functionality, and the semantics of some web services may change. For instance, a particular web service may have been released initially with just three parameters in its input, but a fourth parameter was felt necessary after two years of service. Some older clients will still access the web service with three parameters and newer clients will pass four parameters to it. C'est la vie. One of the most obvious examples of this is when mobile apps access a web service. Some phones will have older releases of the mobile app and others will have newer releases. This makes it necessary for the web service to serve all generations of clients without breaking any.

One way to handle this is by adding an "API version number" parameter to each web service. This will be a mandatory parameter from Day 1. Initial versions of clients will all be designed to use "ver": 1 in their requests. When the software on the server-side application is upgraded and the semantics of a web service change, then it will support the old semantics under "ver" = 1 and newer semantics with "ver" = 2. Newer clients which are aware of the updated semantics will use ver=2 in their requests, with the new semantics. Older clients will not be aware of any changes.

The version number applies to each web service in isolation. The service as a whole may have versions 1 and 2 supported for some calls, 1, 2 and 3 for other calls, and just 1 for calls which have not changed at all.

This will go on, and new generations of web services will keep getting released. This will allow a single service to service multiple generations of clients at the same time.