I am hoping to build an API that will be available to other organizations to pull data specific to their organization from our database.
Once I give each of the organizations an API key, what would be the best way of matching up these keys against the organization so I can provide them with the correct data?
I've considered having a mapping in the database of the keys vs the organization, but feel like there must be a better solution?
Many thanks
Related
I am trying to create and publish APIs from different service providers and publish them as a common solution (under a single API store). Currently, I am trying to make the API names simple and descriptive like action(verb)-onwhat(noun). For example I am having a API that gets a list of FOOs, I would name the API as List-FOO. So simple right?
But the real problem arises here. As I said I am doing it for multiple service provider, chances are I would have API to list the FOOs specific for another service provider too. Even I thought service_provider-action(verb)-onwhat(noun) like ProviderA-List-FOO.
But I dont think that would make sense if I want the store as a common one. Is there anything that I am missing or is there a better way to name the APIs in store to avoid these kinds of issue? Any help is highly appreciable.
based on the given requirement, I can suggest you define separate API packages for each service provider. for example, you can create new API for ProviderA and define all services of ProviderA as the resource paths under that API.
I have been researching the Airbnb API and have started working with it and making some requests. Some API calls such as calendar_months require an API key:
https://www.airbnb.com/api/v2/calendar_months?key=your_api_key&listing_id=17794278&_format=with_price
I know that your API key can be found in the meta tags, or by inspecting requests in the browser (How to acquire API key for Airbnb). This is fine, and I've successfully located my API key.
My concern is that this key does not appear to be unique. I've retrieved the API key from multiple computers on multiple networks with separate IP addresses -- even from a server in another country with no association to my previous Airbnb activity. I always find the same API key: d306zoyjsyarp7ifhu67rjxn52tv0t20
I'd normally never post the key for my account somewhere (obviously), but it's clear that this API key is not unique to me. A quick google search shows that many people are already using it:
https://www.google.com/search?q=d306zoyjsyarp7ifhu67rjxn52tv0t20
You can find the same situation with API key 3092nxybyb0otqw18e8nh5nty. This one I initially found in the old unofficial airbnb api docs (Does you have a copy of a documentation of unofficial AirBnb API?) so it's understandable that some people might have found it there and started using it.
I've searched extensively to find some discussion on this, but I can't find anything and I have a number of questions about this:
Look up your own API key and do a google search for it -- is anyone else sharing your key?
Do you receive different keys on separate computers / networks?
Why would Airbnb require a key for certain requests, if the key does not to uniquely identify the user?
Is there something I'm overlooking which would allow them to identify me even though many people are sharing this key?
How can I acquire a truly unique API key?
Why is no one talking about this?
Thanks!
I have check my airbnb API Key again, it is the same with yours: d306zoyjsyarp7ifhu67rjxn52tv0t20
Just Before I looked this question, I thought this key is unique to my account.
Look up your own API key and do a google search for it -- is anyone else sharing your key?
No one is sharing your airbnb key, and everyone is sharing this key.
Do you receive different keys on separate computers / networks?
No. I have checked in different computers/networks
Why would Airbnb require a key for certain requests, if the key does not to uniquely identify the user?
I have found that Airbnb use IP address to identify different user.
Is there something I'm overlooking which would allow them to identify me even though many people are sharing this key?
I guess there are another parameters help airbnb to identify different users. But I didn't find yet.
How can I acquire a truly unique API key?
Don't Know. Only the Airbnb Engineering Team knows.
Why is no one talking about this?
I thinks everyone will think this key is unique to him/her.
I am researching on the technologies available to build a social network website. The front-end portion has been decided, but I am still unsure about the back-end. The back-end will also be handled by an server running NodeJS. I was planning on using something like MongoDB, or even a combination of MongoDB and a relational database, but I do not know what the best practices are.
I stumbled upon an article that talked about using GraphQL with different types of database structures. The writer mentioned SQL, Redis and MongoDB for their user data, but I did not quite understand their sturcture, or if it would work for mine.
Basically I would like to have users to sign up to my page and add descriptions about themselves, have friends, join groups, upload media (pictures and videos), etc. A pretty basic social network setup, but ultimately the question narrows down to:
"What database structures are best for what?"
Should the SQL handle: userID, email, password
MongoDB: about, description, posts
Redis: cache for something like posts feed
And how would you handle media uploads? SQL, MongoDB? I have not found any useful articles that talk about using different database structures and most of the other StackOverflow questions feel outdated. They either favor one or another, but not a combination.
TL;DR: There aren't really any particular databases you "should use for GraphQL." Just use whatever is best suited for your data and requirements.
I'll give you a rough idea how we use it at work. We have an app that lets users upload songs and videos for us to distribute to digital streaming platforms, e.g. Spotify and such.
We use Postgres to handle all of the app's "transactional data." This is user account info, their song/video metadata, where to send the money, other stuff for the app, etc. All these data are a mere few-hundred MB.
Multimedia uploads go to AWS S3, and the location of each file is stored in Postgres.
The "analytical data," regarding how well each song did on each platform, e.g. number of streams and money made in each region, is stored in Google BigQuery. There is much, much more of these data and Google BigQuery is more equipped for this size.
Of course, the question of which data store one should use is highly case-dependent. GraphQL didn't really influence any of these decisions. The nice thing about GraphQL is that the resolvers let you pull data from anywhere and conglomerate it all into a single API response. By using GraphQL you should feel liberated to use a variety of databases, each well tailored to the type of data it handles.
Well, GraphQL as methodology has nothing related to dbs - it's about how to organize API level of application. It means you should configure graphql schema (tables or entities, own fields, ect.) and set up resolver to fill out response model.
In case if you don't want to do it - you can use solution from the box, like NReco.GraphQL
I have created an API and I would like to allow other developers to get the information from it. So the idea is to generate and assign API keys to everyone that wants to query our information. With API keys I can limit the daily requests and secure my data.
The thing is, I am concerned about the security aspect of it. Since the API key is going to be sent to our server (via GET/POST etc)?
I am looking for the best solution to handle this problem.
The solution in my mind is to use Asymmetric Cryptography to handle this.
Is it the right way to handle this? If not what is the best way.
Any help will be highly appreciated.
I'm going to try to phrase this as a generic question.
A company runs a website that has a lot of valuable information on it. This information is queried from an internal private database. So technically, the information in the database is the valuable part.
If this company wished to develop an API that developers could use to access their database of valuable & useful information, what approach should the company take?
It's important to give developers what they need. But it is also important to keep competing websites from essentially using the API to steal everything and essentially steal all traffic from the company's website.
Is there was some way the API could be used in a way that drives traffic back to the original company's website somehow? Something that gives users a reason to keep going there.
This is a design consideration that my company is struggling with that I can imagine other web-based services have come across before.
Institute API keys - don't make it public. Maybe make the signup process more complex than "anyone with an e-mail address".
Rate limit the API based on keys. If you're running more than X requests a minute, you're likely mining the database.
Don't provide a "fetch everything" API. Make the users know something to get information on it. Don't reveal what you know.
I've seen a lot of companies giving out API keys and stating a TOS that all developers must adhere to. For example, any page that uses data from the API must include your logo and a link back to your website. If any developer is found breaking the rules, the API key can be cancelled and your data is safe again.
Who is meant to use the API?
A good general method of solving this problem is to limit access to the data to end users (rather than allow applications or developers at it). Provide applications and users with identification, each, and make sure that to access a subset of the data, a combination of both user and application key is required.
Following this pattern, each user will have access to a very limited subset of the data (presumably, the data that they require for their own specific use), and you can put measures in place to enforce this. Any attempts at data-mining will become obvious.
This type of approach meshes well with capability-type security models on the server side.