Greetings,

I am interested in creating a website that offers free APIs for use in various projects. For instance, you could use the API to obtain search results or access the MyIP API. I am open to suggestions for other APIs that would be helpful.

There is only one restriction I will impose, which is a limit on the number of requests per second.

If I proceed with this idea, would you be interested in using it? Please note that any financial support would be voluntary donations (No Stupid Memberships, Credits, or any pay-to-use)

Thank you.

    • ChaoticNeutralCzech@beehaw.org
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      I think they mean an API-aggregating API that would be called “100% API” with loads of services supported but no idea how to pay for all that.

  • MJBrune@beehaw.org
    link
    fedilink
    English
    arrow-up
    54
    ·
    edit-2
    1 year ago

    No, I do not want or need a middleman whose only job is to pass my data through to another API. It’s a huge security risk and potentially a violation of my and my user’s privacy. Pretending everything is perfect, it’s still another point of failure. Your API service could become unavailable. Your API service could simply wrap others in a huge library and still that means some of them are going to be outdated.

    There is no strong reason to do this unless you are binding these services together to create a new platform, like what game engines typically do. They take a rendering library, physics engine, etc., tie them all together with an implementation, and allow you to build the higher-level stuff. If that’s your idea but for web development or something then I could see the use but just “everything goes in this monolithic API” is not only a terrible idea, it’s a dangerous one.

  • ulkesh@beehaw.org
    link
    fedilink
    English
    arrow-up
    26
    ·
    1 year ago

    There is only one reason to use an API — a developer has a use-case for it. Setting aside all of the security concerns, the existence of some API proxy is not useful in and of itself. Not only is it dead simple to set something like that up, by oneself, thus eliminating the security risks of relying on a third party, it’s just not going to gain traction if it doesn’t add something that makes it more useful than simply calling the endpoint API.

    It’s cool you’re looking to try things, but perhaps coming up with a novel service would be a better use of time and effort.

    I wish you luck.

  • moog@lemm.ee
    link
    fedilink
    arrow-up
    22
    ·
    1 year ago

    why would i not just use the api your api hits ? are you talking about footing the bill for paid apis? then no because youre going to stop paying for those at some point.

  • Scary le Poo@beehaw.org
    link
    fedilink
    arrow-up
    14
    ·
    1 year ago

    Bro wut?

    I bet every dollar I have that you don’t have the foggiest idea of wtf you’re talking about.

    • MJBrune@beehaw.org
      link
      fedilink
      English
      arrow-up
      22
      ·
      1 year ago

      they are talking about an API that wraps all other APIs so you only need to include one API. It’s like the opposite of microservices. Monolith services by force.

  • elauso@feddit.de
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    Honestly I would probably not use it. One if the most important things I’m looking for in an API is reliability - and a project that has no financing is really just waiting to have its plug pulled.

    You might be highly motivated right now to keep it going for many years. But without a steady income it might just be a burden to keep it going at some point.

    (Nothing personally obviously, I don’t know you and wish you all the best!)

  • blah@lemmy.1204.org
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    Here is a possible case study for you. https://OpenRouter.ai.

    They are doing what you think of doing, for the various LLM APIs. Three reasons why they offer added value:

    1. Some people cannot access some of these APIs directly (GPT-4 in the advanced settings, Anthropic’s Claude is still close access)
    2. They abstract the way these API are accessed so that the code to use different models does not have to change much.
    3. For some reason, they cost the same as the original API
  • mrGarbanzo@beehaw.org
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    I’ll carry the odd opinion here and say there’s actually a way this could be useful. You have to add value to a product to make it worth your time and effort, increase adoption, and make it at least self-sustainable. Find reasons to justify why this should exist. For a start - This could save time on projects where similar data has to be loaded on a page from multiple api endpoints but it doesn’t match. - an old example, but one that I fought once - looking up the time zone of a city from one api, then the time offset from UTC from another api, and trying to relate it all together. That meant my functions had to match that data up on the client side because there were imperfect text matches.

    As a second example, if you were able to cache or keep record of data from upstream endpoints that often takes a while to gather because they can’t/won’t, you might offer a performance advantage or datasets which were previously unavailable to a user without monitoring data coming from that API over an extended period of time.

    There’s more you can do, but that hinges again on what I previously said, find your pitch and solve problems that the others have created and won’t fix.

  • ChaoticNeutralCzech@beehaw.org
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    It could work if you aggregated incompatible providers in the same category (such as weather) into one big aggregate API. That way, people wouldn’t need to refactor if their favorite API provider ramps up pricing or dies. But how would I trust you to keep offering the same service at a good price point instead of an established meteorological institution? Also, I think weather aggregators already exist.