-
- 2.1. Prerequisites
- 2.2. Installing
-
- 4.1. DTOs
- 4.1.1. UserDTO
- 4.1.2. ProfileDTO
- 4.1.3. GenreTagDTO
- 4.1.4. PlatformTagDTO
- 4.1.5. EventDTO
- 4.1.6. RegistrationDTO
- 4.2. URL Endpoints
- 4.2.1. Authentication
- 4.2.2. POST Requests
- 4.2.3. GET Requests
- 4.1. DTOs
This project is the backend portion of the gaming friend finder project. The backend was built by the 455 team, and the front-end website was built by the 106 team. The overall project is meant to be a resource for people interested in gaming to find friends or others interested in gaming and creating events together. Users can find others with similar interests, and invite them to related events.
These instructions will give you a basic understanding of the functions of the server and how to interact with it when developing the front-end counterpart.
Requirements for the software and other tools to build, test and push
A step by step series of examples that tell you how to get a development environment running
Say what the step will be
Give the example
And repeat
until finished
End with an example of getting some data out of the system or using it for a little demo
All tests for this project are end-to-end tests contained within the src>>test>>java>>edu>>lawrence>>friendfinder folder. To run them, depending on your IDE, you should be able to right click on the file and click on an option similar to "Run Tests".
Note that running these tests only works if you have the backend opened yourself as a developer. There is no way to run them by interacting with the server through HTTP.
DTOs (Data Transfer Objects) are the format for JSON objects that will be sent to and from the server in the body of the requests and responses. You must follow these formats to get the server to work.
{
username: [String]
password: [String]
token: [String]
}
{
user: [String]
fullname: [String]
emailaddress: [String]
countrycode: [int]
phonenumber: [String]
bio: [String]
genres: [List<String>]
platforms: [List<Strings>]
}
The "user" field is userid of the user associated with this profile. The genres and platforms lists will be turned into the tag objects on the backend, but should be sent as Strings if they are within a ProfileDTO.
Genre Tags represent the genres of games that the user is interested in.
{
profile: [Integer]
name: [name]
}
Platform Tags represent the gaming platforms the user uses.
{
platformTagID: [Integer]
profile: [Profile]
name: [String]
}
{
userid: [UUID]
name: [String]
description: [String]
location: [String]
timeZone: [String]
startTime: [String]
endTime: [String]
numRegistered: [String]
}
{
eventid: [Integer]
userid: [UUID]
}
As a rule of thumb, GET requests will return a DTO of the object you're requesting, and POST requests will return a DTO copy of the object you posted to the server. Also, for many of the POST requests, the user field will automatically be assigned to the user submitting the request based off of the authentication header.
Most of the HTTP Requests (except registering and logging in) require authentication. This means that to be granted access to the resource the user is requesting, they must send their authentication token within the HTTP header. This takes the form:
Authorization: Bearer <token>
where <token> is is the token they received from the login request and Authentication is the name of the correct header.
Thus, the authentication is linked to them logging in, and they must do so before being able to access the other portions of the server.
[baseurl]/users
Request body should include a UserDTO with a unique username and password.
[baseurl]/users/login
Request body should include a UserDTO with a unique username and password. The return body will send back the same object with the assigned authentication token. Thus, the front-end should save this token for the user for authentication in future requests.
[baseurl]/users/profile
Request body should include a ProfileDTO. The profile is linked to the user submitting the request, and only one profile can exist per user, so if one already exists an exception will be thrown.
[baseurl]/events
Request body should include an EventDTO. The user posting this event to the server is assigned to the role of the host the event.
[baseurl]/registrations
Request body should include a RegistrationDTO. The userid and eventid must correspond to objects that already exist in the database.
[baseurl]/users/profile
Returns the ProfileDTO corresponding to the requesting user.
[baseurl]/users/events
Returns a list of EventDTO objects corresponding to all events in which the current user is assigned to be the host.
[baseurl]/events
Returns a list of EventDTO objects corresponding to all events that have yet to begin.
[baseurl]/events/{id}
The {id} field should be replaced with the id-value of the event being requesed. Returns an EventDTO object corresponding to that event.
- Creative Commons - Used to choose the license
- Spring Security - User authentication
- Spring Data - Data repository creation and management
- Hibernate - Used for interacting with the database
- Spring Boot - Construction of server application and REST controllers
- REST-Assured - End-to-end controller testing
Professor Gregg will send all contributors an email whenever he deploys a new version of the backend on the website. The new version is then live. This repository will not necessarily match that version since this repository has the most up-to-date version, but it should hopefully be as accurate as possible.
- Jack Stuart - Project Co-Creator - Github
- Henry Roach - Project Co-Creator - Github
- Billie Thompson - Provided README Template - PurpleBooth
This project is licensed under the CC0 1.0 Universal Creative Commons License - see the LICENSE.md file for details
- Thank you to the 106 team for building the matching front-end for this project
- Thank you to Professor Joe Gregg for the class, examples, and assistance as we learned and worked on this project