API specification

[bregySilvan]

Description

• This issue is used to specify our API. Pls always update this issue when editing API or adding new locations to API.

Interfaces

 IBoard {
   title: string;
   description: string;
   imageURL: string;
} 

 IBoardInfo {
   id: string;
   title: string;
} 

API

request type	location	payload	response
get	/title | { } |{ titles: string[] }
get	/title/ | { id: string } |{ title: string }
get	/data | { } |{ data: any }
get	/board/ | { id: string } |{ board: IBoard \| null }
get	/boards | { count: string } |{ boards: IBoard[] }
get	/boardlist | { } |{ boardInfos: IBoardInfo[] }
post	/board/${id} | { id: string } |

history

13.03.2018 add /boardlist location for reading out all board titles with its ids. 13.03.2018 add interface IBoardInfo which holds an id with a title. 13.03.2018 change all numbers to strings 14.03.2018 removed get title/id 14.03.2018 add /board/id on which will happen a Post-Request 21.03.2018 remove id from /board and /title. They have only a payload

[Christian-Seematter]

Good work! I recommend you move this to a fixed document though (gitub wiki) unless you want to use this issue to talk about the current implementation. You should do that in person in class though.

Try to be as specific as possible when defining an interface like this. IBoard is not going to work as actual payload, the API interface should be as language neutral as possible. You can define what makes up a board as a shortcut, but that still needs to be valid JSON so there is no way the interface can be misinterpreted. To achieve this:

• [x] The keys need to be strings
• [ ] The boards array leaves multiple ways of implementing the array in JSON.

[olinator98]

@bregySilvan Nice work, now our specification is identical with our code! Good job, cherio! #35 has been closed!

[olinator98]

@SvenHutter @noulyn Please have a look at the latest changes including the definition of the post-request.