Hi all! Getting back to the previous e-mails, we've done several implementations based on the feedback provided. The main changes are: * Provide reviews id at the review body. The id now is provided under the field "name" (NOTE that the schema to POST reviews has changed) * Regarding reservations and Occupancy: - Added additionalProperties "capacity" and "occupancyLevels" at every Restaurant (NOTE that the schema to POST restaurants has changed) - Provided a new Route [1] that given a Restaurant and a date, returns the Restaurant with the occupancyLevels at that time (it calculates the reservations from -2 hours of the given date). - Provided a new Route [2] that retrieves all the reservations between the dates provided (params "from" and "to") All the changes are reflected in Apiary and the documentation is updated. Let us know if you have any doubts. Best! Alberto Martín [1]: http://docs.tourguide.apiary.io/#reference/api-especification-for-tourguide/restaurant/get-restaurant-with-a-given-date [2]: http://docs.tourguide.apiary.io/#reference/api-especification-for-tourguide/reservation/list-reservations-by-restaurant-and-date On Wed, Jan 20, 2016 at 3:58 PM, Jaisiel Santana <jaisiel at gmail.com> wrote: > Hi! > > thanks for you response. We will be waiting for your decisions before > continue with these working lines. > > > Regards, > > Jaisiel Santana. > > On Wed, Jan 20, 2016 at 11:31 AM, Alberto Martín Casado < > alberto.martin at bitergia.com> wrote: > >> Hi! >> >> Comments inline. >> >> On Wed, Jan 20, 2016 at 11:03 AM, Jaisiel Santana <jaisiel at gmail.com> >> wrote: >> >>> Hi! >>> >>> We are updating the client of the tour guide and some questions have >>> arisen. We would appreciate if you can answer it. >>> >>> >>> - >>> >>> We found that the API allows to write more than one review per user >>> about the same restaurant. Is this behaviour correct? >>> >>> >> Yes. We conclude that a user can go to a restaurant once, twice or more >> times; and the service each time can be different, so we let the reviews >> open to more than one. >> >> >>> >>> - >>> >>> If we retrieve a set of reviews, the ids are not listed. We need >>> them to update or delete reviews, we also noticed that they are not >>> specified in the responses located in the API specification. >>> >>> For example, if we request for: >>> http://compose_devguide_1/api/orion/reviews/restaurant/Ondalan we get: >>> >>> >>> [ >>> >>> { >>> >>> "@context": "http://schema.org", >>> >>> "@type": "Review", >>> >>> "author": >>> >>> { >>> >>> "name": "user5", >>> >>> "@type": "Person" >>> >>> }, >>> >>> "itemReviewed": >>> >>> { >>> >>> "name": "Ondalan", >>> >>> "@type": "Restaurant" >>> >>> }, >>> >>> "name": "Rating description", >>> >>> "publisher": >>> >>> { >>> >>> "name": "Bitergia", >>> >>> "@type": "Organization" >>> >>> }, >>> >>> "reviewBody": "Body review", >>> >>> "reviewRating": >>> >>> { >>> >>> "ratingValue": 4, >>> >>> "@type": "Rating" >>> >>> } >>> >>> } >>> >>> ] >>> >> >> True. Actually the 'id' field it's a field that breaks the Review schema >> in schema.org, that's why we did not add it. I'll have a look again to >> try to find a way to add it in every review response (as in Orion it's >> already there but not being displayed in our API). >> >> >>> >>> >>> - >>> >>> Have you considered to add restrictions to make reservations? >>> (number of commensals, schedule ,maximum of reservations...) In that case, >>> how can we retrieve this information? >>> >>> >> Reservations are restricted already. The procedure we've follow is: >> >> - Everytime a user try to create a reservation, the application >> calculates how many reservations has been done in the previous 2 hours of >> the time we want to reserve a table. >> - If there's enough space, the reservation can be done; and if not, is >> discarded. >> >> We have a script to update that information into the restaurants: >> https://github.com/Fiware/tutorials.TourGuide-App/tree/master/server/feeders#occupancy-updater >> >> We are still thinking on how to 'automate' this occupancy levels into the >> restaurants (as I guess is the information you need). >> >> Also, we can discuss on how can we display this information and what's >> better for the client side, so we can talk a bit deeper about it to match >> your requirements. >> >> >>> >>> - >>> >>> We can’t access to the API specification in Apiary ( >>> http://docs.devguide.apiary.io/#reference/api-especification-for-devguide/). >>> We suppose that the project name has been changed according to the new >>> nomenclature. Can you provide us the new url? >>> >>> >>> >> Yes, sorry. I've updated in the repository thinking that it would work as >> github does (doing redirections) but seems not. It has been changed from >> 'devguide' to 'tourguide': http://docs.tourguide.apiary.io/. Sorry for >> the inconvenience! >> >> >>> >>> Regards, >>> -- >>> Jaisiel Santana. >>> >>> _______________________________________________ >>> Fiware-developer-experience mailing list >>> Fiware-developer-experience at lists.fiware.org >>> https://lists.fiware.org/listinfo/fiware-developer-experience >>> >>> >> Best, >> >> >> Alberto Martín >> >> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-developer-experience/attachments/20160202/bd69615b/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy