Places Endpoints

[AlejandroPOcz]

Please see our RFC and help us checking if there's anything missing or anything that can improve.

[gh0stl1m]

@AlejandroPOcz Congratulations for the good work here. It is pretty clear and the structure of the document is pretty good. Besides the contracts defined for endpoints are good and clear which is important in order to create an ubiquous language for other teams.

Most of the contracts defined are good but it would be great if we add to the RFC which standard are we using and why. As I could see in the RFC we are using API REST so let's add what's REST and why are we using it.

Related to the contracts there is just one that which is the PUT /places/{place_id} because we should change it for PATCH due to the PUT verb is used to modify the whole document and for our business case we should only modify one portion of it.

There is a question that would be great that we consider also. Should be have a service that removes a place? if does we should perform a soft delete or a hard delete?

Pretty good job folks. Let me know if you have more doubts.

[AlejandroPOcz]

Santiago!

Thank you for the observations. I'll update the RFC.

[jacorreamed]

Hello @AlejandroPOcz I have a question, how can I apply a filter over the list of places that I fetch by the /places/ method? . I say that because we (admin team) are thinking on use this API to fetch date for our places table.

[Edilberto-Vazquez]

I see your RFC #36 and the RFC database https://github.com/Platzi-Master-C9/knowledge-base/discussions/ 35 and I see that both have different data when the data is transferred through the endpoints and stored in the database. I made a diagram to better understand how this happens https://github.com/Edilberto-Vazquez/knowledge-base/blob/main/RFCs/accepted/0000-geolocation-endpoints.md#detailed-design. If you have any questions or suggestions about geolocation RFC endpoints, please let me know via Slack @edilberto Vazquez Luna [C9] or here #32