dkurok

Members
  • Content count

    62
  • Joined

  • Last visited

  • Days Won

    12

dkurok last won the day on May 13

dkurok had the most liked content!

About dkurok

  • Rank
    Level 3 Stud

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Lego, singing acapella

Recent Profile Visitors

523 profile views
  1. dkurok

    Not receiving full JSON set inventories from API?

    HangryDave, I had the same problem (also remarked in your mentioned thread from feanferr) and I can only recommend to ALWAYS inspect the value of the "next"-field in the JSON-result: { "count": 263, "next": "https://rebrickable.com/api/v3/lego/sets/7965-1/parts/?page=2", "previous": null, "results": [ {... It is possible, even if you use page-size of 1000, that the API doesn't return you 1000 but for example only 100 (it's per configuration and depends on performance and can even be changing dynamically). So to receive the complete result you've got to call the url given by next (if it isn't null) and collect the results until you have next == null. This is the nearly the only way to determine that you've got the full result. And because this is valid for nearly all GET-API-methods, you should try to handle it in general on all your API-GET-calls. The other way to determine is to count your number of results received (the count of elements in result-array) and compare that to the number given in the "count"-field at the beginning. And then you can use next-URL to receive the next page.
  2. As Dragma explained you can use the page_size-parameter. But you should also look into the thread in this forum. Nathan explained that the standard page-size has been lowered to 100 and 1000 is the maximum you can give it in a call. In case your set has more than 1000 parts (unique in part_num and color; is there a set like this?) you have to use the next page URL given by the response-field named "next" in the very beginning of the response. If you want to fill a list or alike in a program/app, you can collect all results by calling first the API-function and then call the URL given by "next" until "next" is null. By this way you are not depending on changes in the defaults Nathan may change from time to time due to performance or other reasons.
  3. since a few weeks there are no more images in new MOC-notifications for followed designers (they are in the emails for general new MOC-emails). Can you bring them back; it makes it much easier to decide whether to open Rebrickable form the email or not; the title of a MOC isn't always that "speaking".
  4. dkurok

    POST /api/v3/users/_token/ in Android

    Hi Dragma, I guess that {mykey} will really be replaced with your API-key here and you've used the {myKey}-notation just for clearing out your real key. If not, there may be a problem here. At the end of the day when going over the wire, post-data key-valuepairs have to be separated by a "&" and not ",". Otherwise the comma will be part of the password and this breaks your authorization (which explains the 403 - Not authorized) Maybe it helps Dietmar
  5. dkurok

    throttle in API

    Hi Simon, yes, some more information in download-files which are updated on a regular base (should be determined by the frquency of part/set-updates and alike by Nathan) would be very nice. Best regards Dietmar
  6. dkurok

    throttle in API

    Hi biodreamer, just a question about your explanation / clarification: Are you involved in the development of the Rebrickable-API? Or in other words: Do you KNOW for sure that the 28 calls with big chunks are better than the 5000 small calls? In terms of general thoughts I would agree, but the answer for a concrete system like RB depends on a lot of factors (like available bandwith, number of concurrent connections, DB-cache, memory, CPUs,...). So I can imagine a system where the answer would be the oposite (for example good scaling DB with huge cache having all queries for concrete part in cache but small bandwith to the outside world).
  7. dkurok

    throttle in API

    Hi biodreamer, thank you for the explanation! I'm just working on that aspects. I fetch data and cache them in my local DB, but from time to time I've got to consolidate and this is what I actually work on. So knowing that number of calls is more of a problem than "big" chunks on backend-side it good to know. BTW: It seems that pagesize greater 1000 in /api/v3/lego/parts are ignored. Otherwise I could fetch all parts in just two calls: first to get the first 1000 and the count; second to get all in one call using the count of the first call as the pagesize for the second call. But this does not work.... Is that by intention?
  8. dkurok

    Link from Bricklink to Rebrickable throws error

    Didn't expect to find it! Just wanted to point to the behavior of Firefox, which tells something about "corrupted content". So it seams that in some way Rebrickable returns something "malformed" and actually Firefox treats security issues very strict...
  9. Maybe not directly related to API: When searching in Bricklink for a part which not exists in Rebrickable (for example 42601pb01) and then clicking on the Rebrickable-link on the bricklink-site, an error is thrown in Firefox (57.0.4 (64-bit) on Windows 10): "Corrupted Content Error The site at https://rebrickable.com/parts/bricklink/42601pb01 has experienced a network protocol violation that cannot be repaired. The page you are trying to view cannot be shown because an error in the data transmission was detected. Please contact the website owners to inform them of this problem." Using IE or Edge, a Rebrickable-hosted page with a 404-error (Not found) is shown. I tried to understand what problem Firefox has with the page (by using F12 developer tools) and it states something with wrong usage of certificate. But I don't really understand. Not a big problem, but somehow "strange"...
  10. dkurok

    throttle in API

    Hi Nathan, thank you for explanation! Is the number of calls the bigger problem than the calls with big results? So as a (real) example: What is better for your API's infrastructure: A) 28 calls to /api/v3/lego/parts for getting all the actual 27651 parts (with 1000 parts returned in each call) OR ~5000 calls to /api/v3/lego/parts/{part_num} each receiving information for one part? If option A) is better for the infrastructure / performance / ..., could you just add year-from, year_to, [prints}, [molds] and [alternates] of the parts into the results-object of each part returned by /api/v3/lego/parts? This would reduce my number of calls dramatically... Many thanks Dietmar
  11. dkurok

    throttle in API

    I do exactly that in first place; but I also need the Bricklink-IDs, thumbnail_urls, molds, printed,... and so on and so I've got to call API on every part (i own) again (even the content from get /api/v3/lego/parts don't give back the needed fields). The download-files only have basic data...
  12. dkurok

    throttle in API

    Is there a way to get rid of the throttle in API-calls (Status code 429) or get it significantly higher. Actually there is a limit of 2 calls / second. I'm working on a (private; non-commercial) inventory-solution in C#/WPF and I have a database with ~50.000 parts for which I want to update part-information by using RB-API (I also write back my infomration into my RB-account). With a limit of 2 calls/second and handling the 429-status it will take ~7 hours. I think without throttle I could do it in ~2 hours. In the API-documentation it is stated: What is the meaning of "normal user"? How can I become a non-normal user? Best regards Dietmar
  13. dkurok

    api with google doc

    Can you explain a use-case you want to archive? It should be possible because (AFAIK) scripting in Google Sheet is more or less pure JavaScript and the Rebrickable API can be called also by JavaScript. But what do you want it to do in a sheet? I did a full Swagger-documenation (with modelling of the results) of the complete Rebrickable-API. And by using Swaggger-codegen one can also generate a JavaScript-Client-library from it. I'm using it for my private C# / WPF application for an inventory of all my sets and loose parts...
  14. dkurok

    search-parameter in /api/v3/users/{user_token}/parts/

    Nathan, thank you for the information!
  15. The API-function /api/v3/users/{user_token}/parts/ has a query-parameter named "search". Has someone investigated how this parameter can be used ? Does it understand wildcards? For what kind of search (and on which fields) is it used? Same parameter also exists for /api/v3/users/{user_token}/sets/ How does it work there / can it be used there? Many thanks!