I'm using listings api to get listings, inventory and variations in one shot:
https://openapi.etsy.com/v2/listings/123456789?includes=Inventory,Images,MainImage,Variations,Attributes&api_key=XXXXXXXXX
And I would like in addition the relation between variations and images.
So for that point, the variation-images api is fine:
https://openapi.etsy.com/v2/listings/123456789/variation-images?api_key=XXXXXXXXX
This give me back the following associations : (property_id, value_id, image_id) !
But now when I try to get all-in-one (adding VariationImage to ?includes) :
https://openapi.etsy.com/v2/listings/123456789?includes=Inventory,Images,MainImage,Variations,Attributes,VariationImage&api_key=XXXXXXXXX
I get a 400 response:Model ShopListing has no association named VariationImage
however this association is present in the list of possible associations of the official documentation.
Do you have a tip to get this relation in one shot ?
Related
For instance,
I have a team entity and API to retrieve teams will be like this:
GET \teams
To retrieve a single team
GET \teams\{team_id}
and so on...
What name will be good if I need to return a short version of the team's list that include only id and name - like select options.
The options below feel incorrect...
GET \teams\select and GET \teams\short
GET \teams\list
GET \teams\dropdown-options
GET \teams\options
these options look good
Django newbie here.
I created three models: Band, Album and AlbumType (Live, EP, LP). Album have two foreign keys (from band and albumtype). Ok, so, in the view a make something like this:
bandList = Band.objects.all()
To retrieve all the bands but I can't figure out how to get all the Albums from a Band in the same view.
Any help will be appreciated. Thanks.
By default the related objects (through a ForeignKey on the other model) are accessible trough <modelname>_set zo in this case that is band.album_set (note this is a Manager attribute so you will probably use band.album_set.all() most of the time).
I personally prefer to give al my ForeignKey fields a related_name so I can name the attribute on the other model. The next example gives the Band the attribute band.albums.
class Band(models.Model):
# Band definition
class Album(models.Model):
band = models.ForeignKey(Band, related_name='albums')
# Rest of album definition
Could be great if you share your models definition. But I hope this helps you:
If you want to retrieve the Albums for a specific band:
band = Band.objects.get(...)
band_albums = Album.objects.filter(band=band)
That will return the albums for a band.
If you want retrive albums for all the bands:
bandList = Band.objects.all().select_related('album_set')
This will return the bans as before, but will cache the albums.
I want to build a RESTful API for my small project. There are three simple resources that I have:
- Categories (id, title)
- Posts (id, text, category_id)
- Comments (id, text, post_id)
These are the end points that I need:
GET /categories/ => list of all categories
GET /categories/:id/posts => list of riddles in specified category
GET /posts/:id => get single post
GET /posts/:id/comments => list of comments for specified post
GET /comments/:id => get single comment
POST /posts/:id/comments => create a comment (text comes from POST params)
Is this a good structure for API in this case?
Is this consider to be a RESTful API?
REST doesn't have anything to say about URI structure, so it's not really meaningful to ask if your endpoints are RESTful.
As far as the design, I would consider this instead:
GET /categories
GET /posts?categoryId=<categoryId> -- or you could use category name, if the name is not the same as the id
GET /posts/<postId>
GET /comments?postId=<postId>
GET /comments/<commentId>
POST /comments
{ "postId" : 123, ... }
According to REST, url should uniquely identify the resource which is happening in your case. As long as your url is Cacheable and you are using correct verbs and correct status codes, do not indulge in too much quabble about url structure. Additionally, you might want to look into 'Hypermedia', if you want your apis to be truly restful
The support forums on ESPN.com recommend using Stack Overflow with the ESPN tag. That's why I'm here.
I'm trying to obtain a list of all NCAA college basketball teams using ESPN's Teams API. I started with this GET request:
http://api.espn.com/v1/sports/basketball/mens-college-basketball/teams?apikey=MY_API_KEY
That gave me a list of teams, but many of them are missing. For example, there is no Nebraska. So then I thought that maybe I need to get a list of teams by conference. So I read this in the documentation:
GROUPS: Allows for filtering by "group" or division, e.g. AL East, NFC South, etc. For group IDs and their corresponding values, make a request to http://developer.espn.com/v1/{resource}/leagues. Not applicable to golf and tennis.
So then I try to make a request to `http://developer.espn.com/v1/sports/basketball/mens-college-basketball/leagues?apikey=MY_API_KEY' and it says the page does not exist.
Is this a bug or user error?
First, I think you forgot sports in the resource. Try this:
http://api.espn.com/v1/sports/basketball/mens-college-basketball?apikey=MY_API_KEY&leagues
That will return a mapping of integers to conferences it seems according to the documentation.
That fetched me:
{"name" :"Atlantic Coast Conference","abbreviation" :"acc","groupId" :2,"shortName" :"ACC"}
...and much more.
Then once you have that, let's say 2 = ACC. You should be able to do this:
http://api.espn.com/v1/sports/basketball/mens-college-basketball?groups=2&apikey=MY_API_KEY'
to get everything on ACC mens' basketball teams.
Bear in mind the API is in beta though.
I could not figure out how to get a list of conferences, but I found out how to get the missing teams. When I was making the first get request, it was limiting me to 50 results by default:
http://api.espn.com/v1/sports/basketball/mens-college-basketball/teams?apikey=MY_API_KEY
They have a sandbox where you can play with your parameters, and I saw a limit and offset option:
http://developer.espn.com/io-docs
To get more than 50 results, you have to make multiple requests using the limit and offset parameters.
First Call:
http://api.espn.com/v1/sports/basketball/mens-college-basketball/teams/?limit=50&offset=0&_accept=text%2Fxml&apikey=MY_API_KEY
Next Call:
http://api.espn.com/v1/sports/basketball/mens-college-basketball/teams/?limit=50&offset=50&_accept=text%2Fxml&apikey=MY_API_KEY
And so on...
Im having an issue where I cant decide how to procced on this matter.. and I need to know if there is any standard way to solve this.. or if you guys have any great input for this matter.
The thing is that I have started to build a very basic API for learning purpose
The API is a simple Music store.. where the store has some Albums which requires and artist.
So the Relationship is Artist <--- 1 ----- * ---> Albums and for an album to exist its required that that the album has an artist. But the artist doesnt require and Album.
Now to the problem...
Due to this relationship if I want to create a new Album.. I would have to post the album data.. AND the entire Arist-data..not just the ID of th artist.. but the whole Artist.. which doesnt seem very effective if you ask me.. since that a whole lot of unnecessary.
So as I see it there is two ways to solve this...
either I just post the entire album-data/object and allows the Artist-data for the object to only contain an ID which then reference to the artist.
So instead of posting:
{
"Name":"AlbumName",
"Description":"Some description for the album",
"ReleaseYear": "1992",
"Artist" {
"Name":"Some artist",
"Id":"12345",
"Biography":"Lorem ipsum dolor sit amet"
}
}
I would do this:
{
"Name":"AlbumName",
"Description":"Some description for the album",
"ReleaseYear": "1992",
"Artist" {
"Id":"12345"
}
}
Option number two is to actually have a route/url thats specific for this...
for instance:
/api/artist/{artistid}/album
And then simply post an album-object to that url..
But as I said.. Im really not sure of whats right and wrong here.. or is there any standard way of handling this?
Thanks in advance!
I would suggest something like this.
POST /musicstore/artist/343/albums
{
"Name":"AlbumName",
"Description":"Some description for the album",
"ReleaseYear": "1992",
}
The act of creating a resource as a child of the collection of albums for the artist 343 implicitly creates the relationship between the artist and the album. There is no need to specify it in the payload.
Albums and Artists are two separate entities, you shouldn't post all the artist data into Albums, just its ID.
Therefore you first create the artist if it doesn't exist, and after that you post the album details, artist_id being one of its properties.