dkurok

V3: External IDs in GET /api/v3/lego/parts/

Recommended Posts

I have alot of parts in my inventory for which I have the bricklink-IDs (written on paper :-) ). As an example let's take 4592c02, which, when entered in the search-box on V3, leads me to:

https://rebrickable.com/parts/298c02/lever-small-base-with-black-lever/

This page clearly states the bricklink ID correctly.

Now I want to do the same over API: entering the bricklink-ID and calling an API-function which returns me the correct Rebrickable-ID (298c02 in the example) and a list of external IDs.

I tried /api/v3/lego/parts/ with the search-parameter also, but I cannot find any API-function which returns me the external IDs like it was returned by the V2-function get_part and parameter inc_ext=1. In V2 I could use the Bricklink-ID in the part_id of get_part and it returned me the rebrickable_part_ids, if the part_id was a non Rebrickable-ID.

I think there are different solutions:

  1. Use the search-parameter of /api/v3/lego/parts and extend the result with the external IDs (like in V2); part_ids in the result are clearly Rebrickable-IDs and it is up to the consuming client to evaluate the result; in conjunction with that extend also the result of GET /api/v3/lego/parts/{part_num} so that it contains the external IDs (like it does for print, molds and alternates)
  2. Make /api/v3/lego/parts/{part_num} also react on Bricklink-IDs (and maybe others like ldraw, brickowl,...) and have an external-array in the result (this is pretty much the same behaviour like in V2)
  3. Add extra-functions like /api/v3/lego/bricklinkparts/{part_num} (and the same for maybe LDRAW, BrickOwl, LEGO (designid)), which return at least the Rebrickable-ID of the part

Alternative 2 would suite best to my needs (not much change in my use of the API). From an architectural point of view, 3 would be the best solution (clear separation of concerns). 1 makes sense at all to me (search should search for "everything" (like search on the site) :-) )

Everthing said is just IMHO.. :-):)

Best regards

Dietmar

Share this post


Link to post
Share on other sites

Thanks for testing it out, I'd really like to bed down these issues before too many people start using the v3 api and making it hard to change things! Does this help:

  • The search param for /lego/parts/ now behaves like the site's search box so will find 4592c02 and return it as 298c02.
  • The part details view /lego/parts/{part_num}/ now returns an external_ids dictionary

Share this post


Link to post
Share on other sites

I expect that /api/v3/lego/parts/{part_num}/colors/ will return also element ids for specific color. Can you fix it? Or I should use another way for get element id based on color id and part_num?
 

For example for part_num==54200 and color "Dark Bluish Gray" (72)  Element IDs are 4244373 4504378.

Share this post


Link to post
Share on other sites
On 2/1/2017 at 6:54 PM, slookin said:

I expect that /api/v3/lego/parts/{part_num}/colors/ will return also element ids for specific color. Can you fix it? Or I should use another way for get element id based on color id and part_num?
 

For example for part_num==54200 and color "Dark Bluish Gray" (72)  Element IDs are 4244373 4504378.

Makes sense, I've added an elements list to the call.

Share this post


Link to post
Share on other sites
2 minutes ago, Nathan said:

Makes sense, I've added an elements list to the call.

excellent. thanks.

may be name element_ids would be better. but up to you

Share this post


Link to post
Share on other sites

Hi Nathan,

I have to follow this up again:

I tested the new version of the   /api/v3/lego/parts and  /lego/parts/{part_num}/ and took another (very popular) part: Bricklink ID : 4073

When I give that into the search-parameter of parts-function it returns two results:

 

{
  "count": 2,
  "next": null,
  "previous": null,
  "results": [
    {
      "part_num": "24073",
      "name": "MINI HAT NO. 12",
      "part_cat_id": 27,
      "part_url": "https://rebrickable.com/parts/24073/mini-hat-no-12/",
      "part_img_url": "https://m.rebrickable.com/media/parts/elements/6138681.jpg"
    },
    {
      "part_num": "6141",
      "name": "Plate Round 1 x 1 with Solid Stud",
      "part_cat_id": 21,
      "part_url": "https://rebrickable.com/parts/6141/plate-round-1-x-1-with-solid-stud/",
      "part_img_url": "https://m.rebrickable.com/media/parts/elements/614126.jpg"
    }
  ]
}

The second one is the wished ones (I know by manual lookup).

So now I've got to traverse through each result (the bricklink-match is not necessary the first one), call parts/{part_num) for it and look through the results and hopefully find the one which has my searched Bricling-ID in the external_ids-property.

This make really a lot of calls to your API, each of them stressing your network (Take for example "112" as search criteria and it returns 194 results, spreaded over two pages which can make up to 196 calls!).

Can you extend the result-schema of the parts-function in that way, that each match directly has the external_ids?

Or (and from the way the link-URLs from Bricklink to Rebrickalble look like, it seems something like that exists) make an additional API-function  /api/v3/lego/externalids/X/{externalid} with X either being "BrickLink",  "LDraw", "LEGO" or "BrickOwl".  each function has just one path-parameter  and the result is the Rebrickable-part in the same notation as used in part/{part_num}-function. from API-designaspects this option would be the best...but that's up to you

Best regards

 

Dietmar

 

 

Share this post


Link to post
Share on other sites

I'm trying not to add too much data into the List views. I could add the external ids endpoints, but first how about this - I've added an extra filter parameter for /parts called bricklink_id etc which you use instead of the more general search filter. Does this do what you want?

Share this post


Link to post
Share on other sites

Perfect!

Thought it's harder to change existing API-function than adding a new endpoint.

Works nice and fullfills what I searched for!
Big thanxs!

Share this post


Link to post
Share on other sites
On 03.02.2017 at 10:57 PM, Nathan said:

I'm trying not to add too much data into the List views. I could add the external ids endpoints, but first how about this - I've added an extra filter parameter for /parts called bricklink_id etc which you use instead of the more general search filter. Does this do what you want?

Is this already implemented?

https://rebrickable.com/api/v3/lego/parts/?bricklink_id=3070b

or

https://rebrickable.com/api/v3/lego/parts/?bricklink_id=54200

Couldn't find requested parts...

Share this post


Link to post
Share on other sites
9 hours ago, dkurok said:

Perfect!

Thought it's harder to change existing API-function than adding a new endpoint.

Works nice and fullfills what I searched for!
Big thanxs!

In general yes, in this case I'm adding extra data and since I only support JSON now so it shouldn't break existing code. Plus I'm ok to modify bits now while it's still new, but as adoption increases I'll be more hands off.

Share this post


Link to post
Share on other sites
2 hours ago, slookin said:

Is this already implemented?

https://rebrickable.com/api/v3/lego/parts/?bricklink_id=3070b

or

https://rebrickable.com/api/v3/lego/parts/?bricklink_id=54200

Couldn't find requested parts...

This is because those parts are the same at Rebrickable and so they don't have defined Bricklink mappings. I've changed it now so the bricklink_id etc filters will also look at part_num if no mappings exist. I think that's reasonable behaviour as we then assume the numbers are the same between sites which is the same way the part details pages behave.

Share this post


Link to post
Share on other sites
12 minutes ago, Nathan said:

This is because those parts are the same at Rebrickable and so they don't have defined Bricklink mappings. I've changed it now so the bricklink_id etc filters will also look at part_num if no mappings exist. I think that's reasonable behaviour as we then assume the numbers are the same between sites which is the same way the part details pages behave.

Thanks it is usefull.

Share this post


Link to post
Share on other sites

FYI while adding external ids to the colors data, I realised the part external ids should have been lists so have changed this output. Sorry if it breaks anything you have already built, but I figured it's best to change it now.

Share this post


Link to post
Share on other sites
15 hours ago, Nathan said:

FYI while adding external ids to the colors data, I realised the part external ids should have been lists so have changed this output. Sorry if it breaks anything you have already built, but I figured it's best to change it now.

:(  not big problem. but "unexpected" .

Thanks.

Share this post


Link to post
Share on other sites
On 6.2.2017 at 3:37 AM, Nathan said:

FYI while adding external ids to the colors data, I realised the part external ids should have been lists so have changed this output. Sorry if it breaks anything you have already built, but I figured it's best to change it now.

Realized that today! Even though unexpected at that moment (it breaked my code :() it is absolutly correct, because the mappings are not always 1:1 but more like N:M and so it makes 1:N from the Rebrickable's perspective.

Thank you for your quick fixes!

Dietmar

Share this post


Link to post
Share on other sites