Endpoints - IvanAlvarezEnri/dragon-squad-api GitHub Wiki
GET /locations?location=name
This endpoint will return a list of possible locations that the user may write. It will work as a predictive search for the frontend.
Only search locations in our database. We have simulated a registry of 500 rooms spread over 100 locations around Madrid. We have done this creating random latitudes and longitudes near to Madrid and using reverse Geocode to stock the street name. Our objective with that is to achieve the following points:
- Stock ONLY the locations registered by the users.
- By limiting it to the area of Madrid, we can implement an endpoint that returns the rooms to us in locations near the given location, calculating a range with the bounds. If we covered more territory, it would be less efficient to test.
Why we have done this?
- The OpenCage API does not support autocompletion nor partial matching. Tested by us and confirmed by contacting them.
- Pros: It allows a goos scalability and gives us more freedom: we can be more precise at searching, we can sort by countof rooms and show it to the users.
- Cons: Our server wil have more work to do.
Fields
String : location -> Can't be blank. This field gets the text for the location autofill
https://dragonsapi.herokuapp.com/api/v1/locations?location=mad
GET /rooms?lat=X.X&lng=Y.Y&range=Z.Z
We call to ROOMS endpoint which returns a list of rooms that we find with the parameters sent inside the request. The endpoint takes some coordinates such as LATITUDE, LONGITUDE and a RANGE search. The idea behind including a range is to perform a broader search in the indicated distance.
Why we did like that?
- Following this way with this params, we can perform the search from any point and expand our focus by expanding or reducing the range, as if using a zoom on a map.
- Pros: We can find results close to our point of interest, especially if it lacks rooms.
- Cons: We can indicate the coordinates we want without taking advantage of the starting point with the url / locations, this may seem confusing for the user
Fields
Float : lat -> Can't be blank. Latitude
Float : lng -> Can't be blank. Longitude
Float : range -> Can't be blank. Distance for creating a boundary box
Float : max_price -> Can't be blank. Distance for creating a boundary box
Integer : popular -> Optional. 0(ASC) 1(DESC). Order by popularity
Integer : order_by_price-> Optional. 0(DESC) 1(ASC). Order by price
Integer : page -> Optional. 0 by default. The actual page of the room list paginated (20 per page).
https://dragonsapi.herokuapp.com/api/v1/rooms?lat=40.00000000000&lng=-3.000000000000&range=50000
GET /rooms/:id
The ROOMS/ID endpoint returns an object with all the necessary fields of a specific room, this object will be more extensive than the one sent in the previous endpoint. The endpoint collects an ID that can be extracted from the previous rooms list
Why we have done this?
- We have taken this structure because it seems the most logical to have so much resemblance with the usual method SHOW
- Pros: It gives us the possibility to scale the room model and add more fields or even add user information (through a 'join') or location.
- Cons: The frontend has to do another request to our api