We have a resources named Games and Players
/games -> Get all Games available
/games/{game-id} -> Get the game details of specific Game with game-id
/players/me -> Get logged in Player details
There will be Games played by the player which can be tagged under Games or Players
Scenario 1
/games/me -> Fetches games played by the current logged in player
This groups the request under Games tag. I'm using Swagger API so this call will be going to GamesAPI controller on the client generated code. I see its fair to be in the Games api rather than player as its related to games.
Problem : It looks too odd to consider "me" as a special id as it looks it is one form of {game-id} which I can't digest.
Scenario 2
/players/me/games -> Fetches games played by the current logged in player
This groups it under Player tag which goes to PlayerAPI after code generation. The path has a meaning which is good but, its more relevant to have it in GamesAPI (by my choice - I could be wrong, please suggest)
Among these two scenarios which is the better way to design this problem?
Scenario 1 seems to be better among two because in general your games url will land to GameController and there you can have action function for fetching all games, one game of given id, or the logged in user's games.
Relationship design is driven in API's how your schema's are designed .So, in your case
1 Player can play 1 or Many games - So 1 to Many relationship
Hence, you should be grouping game data based of players . So, 2 scenarios arise for an API to have better performance
Scenario 1
Is it easier to search in Games for the player id and then group them?
Scenario 2
Is it easier to search Players on the basis of the Game id and then group them?
Logically, speaking and considering scenario 1 makes more sense , hence
/games/{player-id} -> Fetches games played by the current logged in player
This is how I solved it.
As mentioned with Scenario 1, I see "me" conflicts with {game-id} and confuses users.
With Scenario 2, I see fetching user games from player API isn't intuitive.
So I went with an approach where it tries to keep the endpoints minimal.
I added a new query parameter "playedOnly:boolean" for GET /games which returns all the games related to the player.
This simplifies lot of things. I can still go with /games endpoint and no more confusion!
Related
I am working on a cooking recipe app for google home and I need a way to string several GoogleResponses (SimpleResponse etc..) together without requiring user interaction between them.
I have searched for other answers pertaining to this, and while I have found a few similar questions to mine, the replies tend to be along the lines of "the system was designed for dialogues so what would be the point?".
I fully understand this point of view, however because of the nature and behaviour requirements of the app that I am developing I find myself in need of this particular possibility.
The recipes are divided into steps (revolutionary, I know..) and there is roughly a 1 to 1 correspondence between steps and GoogleResponses.
To give an example of how a typical recipe unfolds it is usually like this (this is a simplification of course):
main content -> question -> main content -> question -> etc..
With each instance of "main content" being a step of the recipe and each "question" requiring user input.
If if was just like this all the time then there would not be a problem, I could just bundle each "main content -> question" section into one GoogleResponse and be done.
However there are often times where the recipe flows more like:
main content -> main content -> main content -> question
With each "main content" being a step in the recipe, it does not make sense in this context to bundle them together into the same response (there is a system for the user to move back and forth between steps).
I was originally using MediaResponses for the "main content" sections as those do not require user input to move onto the next step, but due to various reasons I won't go into here as this is already getting quite long, the project manager has decided that MediaResponses should not be used in this project.
The short answer is the one you already encountered - trying to make conversational actions not-so-conversational doesn't work very well. However, there are a few things you can look into.
Recipe Structured Data
Since you're working on a recipe action, specifically, it may be worthwhile to use the standard recipe support that comes with the Assistant.
On the upside - people will be familiar with it, and you don't need to do much code, just provide markup on a webpage.
On the downside - if you have other requirements for how you want the interaction to go, it isn't that flexible. (For example, if you're asking questions at some of the recipe points, or if you want to offer measurement adjustments based on number of people to serve.)
Misuse the "No Input" event
You can configured dynamic reprompts so you get an event if the user doesn't say anything after a few seconds. If they want to speed a reply, they could ask for the next context specifically, or you can catch the actions_intent_NO_INPUT event in Dialogflow and advance yourself.
There are a few downsides here:
Not all devices support no-input. In particular, for example, mobile devices won't generate this.
This may only be valid for two no-input events in a row. On the third event, the Assistant may automatically close the conversation. (The documentation is unclear on this, and the exact behavior has changed over time.)
Media Response
You're not clear why using Media Response "shouldn't be used", but this is one of the only ways way to trigger an event when speaking is completed.
There are several downsides, however:
There are a number of bugs with Media Response around quitting
On devices with screens, there is a media player. Since the media itself is incidental to what you're doing, having the player doesn't make sense
It isn't supported on all surfaces
Interactive Canvas
A similar approach, however, would be to use the Interactive Canvas. This gives you an HTML page with JavaScript that you control, including being able to generate responses to the server as if the user spoke them (or as if they touched a suggestion chip). You can also listen to events for when the generated speech has finished.
There are, however, a number of downsides which probably prevent you from using this right now:
The biggest is that the Interactive Canvas can only be used for games right now. (But this seems to be a policy decision, rather than a technical one. So perhaps it will be lifted in the future.)
It does not work on smart speakers - only some devices with screens.
Combining the above approaches
One way to get around the device limitations of the Interactive Canvas and the poor visuals that accompany Media Response might be to mix the two. For devices that support IC, use that. If not, try using Media Response. (You may even wish to consider the no-input reprompt for some platforms.)
But this still won't work on all devices, and still has the limitation that Interactive Canvas is only for games right now.
Summary
There is no one, clear, way to handle this... and this isn't a feature they are likely to add given the conversational nature of the platform. However, there may be some workarounds which might work for your scenario.
Hello Stackoverflow,
I'm writing API's for quite a bit of time right now and now it came to work with one of these bigger api's. Started wondering how to shape this API, as many times I've seen on a bigger platforms that one big entity (for example product page in shop) is loaded separately (We can see that item body loaded, but comments are still fetching etc.).
Usually what I've done was attaching comments as a relation in SQL query, so my frontend queried single API Endpoint like:
http://api.example.com/items/:id
And it returned all necessary data like seller info, photos etc.
Logically seller info and photos are small pieces of data (Item can only have 1 seller and no more than 10 photos for example), but number of comments might be way larger collection with relationship (comment author).
Does it make sense to separate one endpoint into 2 independent endpoints like:
http://api.example.com/items/:id
http://api.example.com/items/:id/comments
What are downsides of this approach? Is it common practice? Or maybe I misunderstood some concept?
One downside might be 2 request performed, but on the other hand, first endpoint should return data faster (as it's lighter than fetching n of comments), so page might be displayed faster and display spinner for comments section. This way I'll be able to paginate comments too.
Are there any improvements that might be included in this separation of endpoints? Or maybe I'm totally wrong and it should be done totally different way?
I think it is a good approach if:
The number of comments of one item can be large, because with this approach you could paginate it easier.
If you are going to need to access to the comments of one item without needing rest of item information
I think any of the previous conditions justify this decition, and yes, it is common approach.
I have a list of songs - is there a way (using the Spotify / Echo Nest API) to look up the Spotify ID for each track in bulk?
If it helps, I am planning on running these IDs through the "Get Audio Features" part of their API.
Thanks in advance!
You can use the Spotify Web API to retrieve song IDS. First, you'll need to register to use the API. Then, you will need to perform searches, like in the example linked here.
The Spotify API search will be most useful for you if you can provide specifics on albums and artists. The search API allows you to insert multiple query strings. Here is an example (Despacito by Justin Bieber:
https://api.spotify.com/v1/search?q=track:"' + despacito + '"%20artist:"' + bieber + '"&type=track
You can paste that into your browser and scan the response if you'd like. Ultimately you are interested in the song id, which you can find in the uri:
spotify:track:6rPO02ozF3bM7NnOV4h6s2
Whichever programming language you choose should allow you to loop through these calls to get the song IDs you want. Good luck!
It has been a few years, and I am curious how far you got with this project. I was doing the same thing around 2016 as well. I am just picking up the project again, and noticing you still cannot do large bulk ID queries by Artist,Title.
For now I am just handling HttpStatusCode 429 and sleeping the thread as I loop through a library. It's kind of slow but, I mean it gets the job done. After I get them I do the AudioFeatures query for 100 tracks at a time so it goes pretty quickly that way.
So far, this is the slowest part and I really wish there was a better way to do it, or even a way to make your own 'Audio Features' based on your library It just takes a lot of computing cycles. However ... one possible outcome might be to only do it for tracks that you cannot find on Spotify ;s
Title says almost everything.
I found that the music "Boom - 2006 Remastered Version" has two different IDs that can be found in the App:
3EKjTDAEIdyQqsA9qtb5P2
0zlAqnRv07p9ezzFf3k2ky
But when using the API to get information about each one, it returns the same ID:
3EKjTDAEIdyQqsA9qtb5P2
Is this a bug?
It is unfortunately not a bug, but it is indeed very annoying, and your code needs to be able to handle it.
"Give me info for track A! Ok, here is info for track B, just like you asked".
It is a legacy thing still left in the Spotify metadata model called track redirects (the some concept exist on albums and artist too, but are less of a problem there). It was made so that we could quickly merge duplicate albums. It means that once upon time, there were two "different" tracks on different albums that were identical. We had lots of them on artists pages for popular artists. Labels would very often upload one album for one country and another identical one for another country instead of just saying that one album was available in two countries. Sometimes by mistake, most often because of cross licensing issues between labels and countries.
Track redirects are quite rare though if you look at the entire catalog. Most of these redirect tracks are only surfaced in old playlists and are for instance never returned in search results or artist pages. These days we never merge duplicates like this, but instead make sure only one is shown on artist pages, etc. and link to the other in case one is unavailable in your country. That is the concept called Track relinking in the docs. https://developer.spotify.com/web-api/track-relinking-guide/
I work at Spotify and bump into this problem every now and then. I want to change this so the tracks and album become just regular duplicates, because it is much easier to reason about, but it will take a while to fix. I guess I can update my answer here in a few years when it is done.
my graduate project is about Smart Attendance System for University using RFID.
What if one student have multiple cards (cheating) and he want to attend his friend as well? The situation here my system will not understand the human adulteration and it will attend the detected RFID Tags by the reader and the result is it will attend both students and it will store them in the database.
I am facing this problem from begging and it is a huge glitch in my system.
I need a solution or any idea for this problem and it can be implemented in the code or in the real live to identify the humans.
There are a few ways you could do this depending upon your dedication, the exact tech available to you, and the consistency of the environment you are working with. Here are the first two that come to mind:
1) Create a grid of reader antennae on the ceiling of your room and use signal response times to the three nearest readers to get a decent level of confidence as to where the student tag is. If two tags register as being too close, display the associated names for the professor to call out and confirm presence. This solution will be highly dependent upon the precision of your equipment and stability of temperature/humidity in the room (and possibly other things like liquid and metal presence).
2) Similar to the first solution, but a little different. Some readers and tags (Impinj R2000 and Indy Readers, Impinj Monza 5+ for sure, maybe others aswell) have the ability to report a response time and a phase angle associated with the signal received from an interrogated tag. Using a set up similar to the first, you can get a much higher level of reliability and precision if you use this method.
Your software could randomly pick a few names of attending people, so that the professor can ask them to identify themselves. This will not eliminate the possibility of cheating, but increase the risk of beeing caught.
Other idea: count the number of attendiees (either by the prof or by camera + SW) and compare that to the number of RfID tags visible.
There is no solution for this RFID limitation.
But if you could then you can use Biometric(fingerprint) recognition facility with RFID card. With this in your system you have to:
Integrate biometric scanner with your RFID reader
Store biometric data in your card
and while making attendance :
Read UID
Scan biometric by student
Match scanned biometric with your stored biometric(in the card :
step 2)
Make attendance (present if biometric matched, absent if no match)
Well, We all have that glitch, and you can do nothing about it, but with the help of a camera system, i think it would minimise this glitch.
why use a camera system and not a biometric fingerprint system? lets re-phrase the question, why use RFID if there is biometric fingerprint system ? ;)
what is ideal to use, is an RFID middleware that handle the tag reading.
once the reader detects a tag, the middleware simply call the security camera system and request for a snapshot, and store it in the db. I'm using an RFID middleware called Envoy.