• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by dkurok

  1. I tried allparts-function and it returns both of my 70496. In the result I cannot distinguish/find out from where they are coming (from part-list or from setsminus parts of lost-parts) - but the result -as far as this little test can proof- is fine and together with the /parts-function it fits my needs. Thank you!
  2. Nathan, can you please explain what the function returns? I still get for example: api/v3/lego/elements/6031144/ { "part_id": 11548, "color_id": 70, "element_id": "6031144", "design_id": "88585" } and then with the returned part_id /api/v3/lego/parts/11548/ I receive { "detail": "Not found." } (404) (I used API V3 testpage on for making sure I have no errors in my implementation) So what kind of part_id does lego/elements/{id} return? Best regards Dietmar
  3. I think it would be best if the spare parts of an export a marked as such. So whereever the export is used afterwards, the spare parts can be clearly distinguished from the regular parts. So it depends on the definition of the export-format (not on Rebrickable) to sort these things out. The Rebrickable-API V3 (and also V2) for example clearly marks a part of a set as spare part. Other export-formats may not have this marker. IMHO Rebrickable behaves correct in such cases when it exports also the spare parts (they belong to the inventory of the set as delivered). But to your wish: for some of us it really make sense to have the option to not export the spare parts; so make it an option/checkbox would be "nice to have".
  4. I'm fully with you! Rebrickable should save nearly all my last sortings, filterings,... on a per page base (so different criteria for Partlists, for Setlists, for MOCs,...) Would be nice if we could get that....
  5. Me too! Would be nbice to have it! @TobyMac: Put it in the suggestions-area; than we can vote for it...
  6. Hello, can someone please explain what exactly the API-function GET /api/v3/lego/elements/{id}/ is used for? In detail: - What ID is the parameter in (Lego-Element-ID, LEGO-design-ID,....)? - What is the result? The part_id seems not to be a Renrickable Part-Number Try for example 18862 for the {id} . It returns: { "part_id": 11548, "color_id": 70, "element_id": "6031144", "design_id": "88585" } So this seems to be LEG-Element-IDs and Design-ID for the queried ID. But the part_id is not a valid Rebrickable-ID/part_num... To be honest, I'm not so familar with the way especially LEGO is numbering their parts;so maybe someone can explain here or guide me to some ressource to understand... Best regards Dietmar
  7. Wasn't aware of this behaviour up to now... I just tested /api/v3/users/{user_token}/parts/ with the somehow rare "70496" (I know I've got texactly two of them; one in a set (8285-1) and one in my loose parts). It returns only the one from my loose parts. From the description of the function it should " Get a list of all the Parts in the user's LEGO collection. "; so I also understand both (sets and loose parts). @Nathan, is this an error? Best regards Dietmar
  8. The API-functions: GET /api/v3/lego/mocs/{set_num}/parts/ GET /api/v3/lego/sets/{set_num}/parts GET /api/v3/lego/sets/{set_num}/sets/ GET /api/v3/users/{user_token}/partlists/ GET /api/v3/users/{user_token}/setlists don't have the query-parameter "ordering" even though paging (paramter page and result with next and previous) are implemented. Is this by design? On the other hand I see that the API-function GET /api/v3/users/{user_token}/profile has a page-parameter (no ordering), but the result doesn't have the typical paging structure (count, next, previous) (Which I think makes sense when looking on what the function returns there is no paging needed). Regards Dietmar
  9. Hello Nathan, OK, I understand that. If it is a general framework behaviour, than this is clear... Than I have to find a codepoint where to implement this paging in genereal. The increase to 1000 helps in this special cae, but I see that xou can change it without any notofication (which makes sense for reacting quick on performance issues). Thank you!
  10. Completly with you! Should be remembered on a per page base (so different criteria for Lost Parts, for Set-List and Part-List)..
  11. 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
  12. The V2-Api has the function get_changes (see here for doc of API v2 ). I used this some time ago; now I'm migrating my private app (WPF based; should work offline with own database) for my inventory to V3 and I will also come across this soon. With a function like the old get_changes in API V3 ActionGaz' request would work So I would like to see such kind of function also in V3. Regards Dietmar
  13. Hello, I think the GET /api/v3/lego/parts/{part_num}/colors/ API-function should not have paging. There are only 133 colors over all and I guess there is no part which is available in all colors. Because the page-size itself cannot be set in the API and defaults to 100, this function should always return all colors the requested part is available in. This keeps away the overhead from the consumer to handle the rare case there are more than 100 colors available for a part (are there any?) and in worst case (133 colors for a part) puts 1/3 more to the answer (instead of maybe handling an addtional call for page 2, which normally is more costly on both side (client and server)) - maximum 33 * ~200 bytes = ~7kB more instead of a asecond call. Regards Dietmar
  14. Back to the original suggestion: If you like to have it, vote for it by clicking on the "Like"-heart at the beginning of the post. I would like to see that feature :-)
  15. 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!
  16. 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": "", "part_img_url": "" }, { "part_num": "6141", "name": "Plate Round 1 x 1 with Solid Stud", "part_cat_id": 21, "part_url": "", "part_img_url": "" } ] } 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
  17. dkurok

    3D models of parts

    Vote for it like Nathan wants us to!
  18. Yes, that would be really helpful! Best would be a good kind of grouping (showing headers for groups (with accordiaon or alike; for example for each part-category or for each color) and sorting (example: inside each category-groups sort by color). For an example of what I mean, see an example here: (I know this will not fit to Rebrickable; just an illustration of what I mean)
  19. Nice idea! But there should be really a good guidance and approval by admins on that - otherwise rebrickable becomes "dirty" and maybe messed by advertise by using really non-LEGO-related parts, where the LEGo in the MOC is only used to surround the to-be-advertised product! But I like the idea!
  20. In the "My Sets" overview of the sets (in a setlist) add a button to mark a set as "build/assembled" (see attachment for suggestion) This makes it easier for owners of bigger collections, who have maybe a lot of sets assembeld and don't want to use them in build calculations. Going into each sets details and then doing the same is a little bit awkward. Best regards Dietmar
  21. I just received an email notifying me about a new badge. But the badge itself is named as "Unknown Badge - Level 1" with a picture just having a question-mark (see attachment). The correct one should have been Follower Level 1 I think... Not important - more funny...
  22. 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: 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: 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) 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) 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
  23. I'm fully with you. Would be nice to have a function for adding a part to loose parts list!
  24. Hello, can't await Version 3! Maybe one suggestion for new version: It would be very helpful to have an additional field on each part (set parts + loose parts) where I can write in the location where this part is stored in my collection (~60k parts). Maybe other users have the additional wish to have that per part-color key (when they store same part but different color in different bin). Showing this location in the overview of a Set (MOC or TLG) would b very helpful then to find the parts needed for the build. Additionally a remark-field on a per set base (for My Sets) would be nice. If multiple set of the same ID are in My Sets (for example 2 times 42030-1), there should be a comment for each of them (for example one with "build", the other with "sealed" or "new"). Many thanks!
  25. On ipad with iOS 8.3 (and also previous versions) I don't get the submenu when "touching" on "My rebrickable" in the main menu of RB-homepage. It goes directly into my profile-page. Problem at that is, that there is no way (or better say I cannot find one) to get into lostparts from there. The only way to get into the list of lostparts I know is over "my rebrickable" --> "lost parts". Maybe it does not handle "ontouch" but onl onclick...