chat gpt hat gekocht und verbessert miene "recht schreib ung"
parent
eaac961a46
commit
105fe30ba3
1 changed files with 38 additions and 38 deletions
|
@ -1,38 +1,38 @@
|
||||||
# Technical Handout API description
|
# Technical Handout: API Description
|
||||||
|
|
||||||
## Introduction
|
## Introduction
|
||||||
|
|
||||||
PGG is a software developed to manage, Tracks and help Teachers to Grade their Peer Groups. In this Technical Handout we will describe how the api is handling the requests from the WebUI.
|
PGG is a software solution designed to help teachers manage, track, and grade peer groups. This technical handout describes how the API handles requests from the Web UI.
|
||||||
|
|
||||||
## Why do we want to implement API's?
|
## Why Do We Want to Implement APIs?
|
||||||
|
|
||||||
The API's are crucial for the septation of concern as well as for the modularity.
|
APIs are essential for separation of concerns and system modularity. Using APIs allows for flexibility — enabling multiple frontends to interact with the same backend, or vice versa. There are several architectural design patterns, such as MVC or MVVM, that promote the use of APIs.
|
||||||
If you use API you are more likely to be able to switch between multiple different Frontends or the other way around multiple
|
|
||||||
backends for one Frontend. Their are multiple design patterns thad explain API's and use them like MVC or MVVM.
|
|
||||||
We did use them becaus the project is not large enough to uses one of the design patterns effective.
|
|
||||||
|
|
||||||
## Who is the user?
|
Although we didn’t fully implement a specific design pattern due to the limited scope of the project, we followed modular principles that align with these architectures.
|
||||||
|
|
||||||
The user are Teachers from the schools thad have manny Peer Groups to grade.
|
## Who Are the Users?
|
||||||
|
|
||||||
## What user pains are we solving and/or what gains are we creating for the user?
|
The primary users are teachers from schools who need to evaluate multiple peer groups efficiently.
|
||||||
|
|
||||||
the api solves the need of clear label groups linked to user's linked to projects all this is secured by a password. The goal of the project is to make the entire grading process accessible and secure through the API.
|
## What User Problems Are We Solving and/or What Benefits Are We Creating?
|
||||||
|
|
||||||
## What concrete outcomes do we want to achieve with these APIs?
|
The API addresses the need for clear labeling of groups, linking users to projects, and securing access via passwords. The goal is to make the grading process straightforward, secure, and accessible through the API.
|
||||||
|
|
||||||
the apis make a modular and save way to aces the data in the database for different frontends.
|
## What Concrete Outcomes Do We Want to Achieve with These APIs?
|
||||||
|
|
||||||
## How do we plan to execute the API program to achieve that?
|
We aim to provide a modular, secure, and scalable way to access database content from different frontends. The API abstracts the data layer and allows flexible integration with various user interfaces.
|
||||||
|
|
||||||
we are executing the a staticky linked binary of the Program.
|
## How Do We Plan to Execute the API Program to Achieve That?
|
||||||
|
|
||||||
## What is the architectural style and why have you chosen it (REST, SOAP, GraphQL, …)?"
|
We are deploying the application as a statically linked Rust binary. This approach ensures performance, portability, and ease of deployment.
|
||||||
|
|
||||||
The program provides a REST API thad get used across the world and is Battle tested. Thad is also the way there is a huge amount of documentation.
|
## What Is the Architectural Style and Why Did We Choose It (REST, SOAP, GraphQL, etc.)?
|
||||||
|
|
||||||
## Summary or Conclusion
|
We chose to implement a RESTful API because it is a widely adopted, battle-tested standard. REST offers simplicity, scalability, and extensive documentation and tooling, making it an ideal choice for our use case.
|
||||||
|
|
||||||
over all is the application is a staticky linked rust project with a REST API. The goal of the api is to provide a esy way for all teacher to get all informations over the groups with there feedback to the group work and the grades.
|
## Summary / Conclusion
|
||||||
|
|
||||||
|
Overall, the application is a statically linked Rust project that exposes a REST API. The goal is to provide teachers with an easy, secure, and efficient way to access all relevant group data, including peer feedback and grading information.
|
||||||
|
|
||||||
|
<!-- ## References -->
|
||||||
|
|
||||||
<!-- ## Reverences -->
|
|
||||||
|
|
Loading…
Add table
Reference in a new issue