Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • C Client_Spec
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • allgoallgo
  • API-Clients
  • Client_Spec
  • Merge requests
  • !2

First draft of the specification

  • Review changes

  • Download
  • Patches
  • Plain diff
Open LETORT Sebastien requested to merge spec_1 into master Jul 19, 2019
  • Overview 0
  • Commits 3
  • Changes 3

In the specification file I'll present how to manage the API, every client should follow those recommandations and have to to be integrated to the project (official/supported client).

The sample pseudo code proposed should work whatever the language.

Please give comments and don't hesitate to start discussion like :

Are all names ok ?

they have to be self explanatory, and if possible short and link to the API URL, or view name.

Accessors should be protected ?

  • pro
    access to token have to be limited.

Should they be named _token & _allgo_url if protected ?

  • pro
    self explaining name for developpers.

What should be the behaviour in case of error ?

I defined some errors for simple case, should we describe every failure behaviour ?

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: spec_1