I will build a website of virtual numbers, where the user can buy a number for a certain period of time and, after registering on a platform that requires a number to send a code, my website will receive the code through a webhook and return to the user.
The central question is: which service fits my need?
I thank.
Not sure what your question is but django REST framework wil fit your needs.
Related
I need to use AWS Rekognition service in my app to verify the user and get them logged in into the app. I ended up in a confusion with the API which has 3 options available, the one is called search, searchByImage, and the other one is called compare.
What is the difference between the methods above? And which one is the most suitable for authentication purposes?
Documentation seems to be clear enough and in my opinion searchByImage would be the better than search option for authentication process. For a similar application I used idexFaces method first to index images of user and then used searchByImage method, but the thing is photograph could be used to log in into the app.
I'd like to verify phone numbers of user accounts in my Rails 4 app (by simply sending them a four digit pin number which they'll need to enter back into the app) - which services are available and which ones are the least hassle to implement into a Rails app?
I'd like to verify both mobile and landline numbers internationally, though my main areas will be Europe, the US & Canada, Australia and New Zealand (I am based in the UK).
Your title lists three main SMS APIs, so for services available you already have a good understanding. But there are also APIs that focus exclusively on 2FA / Verification. Here is a list of some, worth noting that it tends to be focused on the user side of the equation (things like Google Authenticator).
Since you ask about ease of integration, a 2FA API (instead of an SMS API) may be far easier (you don't need to be concerned about generating a truly random OTP, or using voice fallback if the user does not respond to SMS, etc).
Nexmo (Disclaimer: I work there.) actually offers both SMS / Voice APIs, and a Verify API built on top of those lower level APIs.
With our Verify API (it's going to be similar regardless of the 2FA API) you'd make a call to https://api.nexmo.com/verify/json and pass along number and brand (to identify your app) parameters. The response will contain a request_id, and once the user provides your app with the code, you'll pass both the request_id and code to https://api.nexmo.com/verify/check/json.
So it's 2 simple API calls, and in the interim you associate the request_id with the user's session. Here's a quickstart on that process.
With Nexmo specifically, if enough time passes without the second API call, the code is sent again, this time with a voice call (or, if the number is a fixed line, just starts with voice).
With our SMS API (again, will be similar regardless of the API) first you'll generate a code - which may sound deceptively simple, if security is a concern you'll need to ensure that the generation is truly random.
Then you'll store the code and send an SMS. With Nexmo, that'd be a call to https://rest.nexmo.com/sms/json with the text of your message, the to and the from*. There's also security concern there because you're storing the code on the same server as it validating it. If that's compromised, the verification flow is as well.
Finally, you'll compare the user provided code to the code you stored.
So the least hassle really depends on you. Is it easier to make two API calls and avoid secure code generation / storage (and potentially get voice fallback for free)? Or DIY the code generation and reduce your integration to a single call to an SMS API?
Twilio developer evangelist here.
You absolutely can use Twilio (or any of those other services) to verify phone numbers. There is a good blog post here that explains the steps you can go through to perform a phone verification via SMS.
As you are looking to verify landline numbers too, you might need to add voice confirmation too, where you call a user up and read out the 4 digit passcode instead. That can be accomplished in a similar way, but by making an outgoing call to the phone number which reads out the individual code using Twilio's text to speech <Say> verb.
Let me know if this helps at all. I'm in the UK too, so do reach out if I can help further.
To start off, I am extremely sorry if my question is not clear but I have very little knowledge about web services in general and the vast nature of varying available information has driven me crazy over the past few weeks. So please do bear with me.
Summary: I want to create a live score update app for android. (I haven't added android as a tag because I do know how to retrieve data from say twitter's JSON api.) However, like the twitter JSON api, I want to be able to add(POST maybe?) data to the Apache 7.0 service that I have running. I then want the app to be able to be able to retrieve this data that I have posted.
I had asked a more generic question earlier and I was told that I should look up some api's. I did that but I have still not been unable to make a break through.
So my questions is:
Is setting up an API on my local web service the correct way to do this?
If so, how can I setup an API that will return JSON objects to the Android app. Also, I would need to be able to constantly update this API with new data.
Additionally, would I also need to setup a database for all this?
Any links to well explained matter would be appreciated too.
Note: I would like to carry this out using a RESTful Web Service through Jersey and use JSON Objects during retrieval.
Again, I am sorry about my terrible knowledge with web services in general despite trying my best to research a lot. The best I could do was get my RESTful Web to respond to a GET with some pre-defined text that I had set in Eclipse.
Thanks.
If I understand you correctly, what you try to do is something like this:
There will be a match or multiple matches of some sort. Whenever a team/player scores someone (i.e. you) will use the app to update the score. People who previously subscribed to the match, will be notified and see the updated score.
Even though I'm not familiar with backends based on Java, the implementation should be fairly similar to other programming languages.
First of all a few words to REST in general. REST is generally needed, when you need to share information between multiple devices and or users. This seems to be the case here. To implement the REST you are going to need an API of some sorts. Within the web APIs are implemented by webservers answering to certain predefined HTTP Requests.
Thus setting up an API on a web server is the correct way.
Next a few words on databases. A database is generally needed, if you want to store information persistently. This might, or might not be what you are planning to do. If there are just going to be a few matches at the same time and you don't care about persistence of the data, you can use Java to store a collection of match objects in memory. I'm just saying it is possible, not that it is a good idea. Once your server crashes or you run out of memory due to w/e reason, data is going to be lost. (Of course within the actual implementation you want to cache data for current matches in some way and keeping objects in memory is way to do so).
I'd recommend to use a database.
Within the database, you can then store and access information about the matches like the score, which users subscribed, who played, etc.
JSON is just a way to represent the data/objects that will be shared between the server and the client. You can use JSON to encode request and response data/bodies.
The user has to be informed about the updated score. There are two basic ways to do so. Push or Pull. With pull, the client will check for updated scores after fixed intervals or actions. With push, the server will notify the client about changed scores which will cause him to update the information. Since you are planning on doing a live application and using Java anyways, push seems to be the better way to go.
Last but not least let's have a look at a possible implementation using
Webserver (API endpoints + database)
Administrator (keeps score updated)
User (receives updates)
We assume that the server will respond to HTTP Requests (POST#/api/my-endpoint) with JSON-Objects.
Possible flow
1)
First the administrator creates a match
REQUEST
POST # /api/matches
body: team1=someteam&team2=someotherteam
The server now will create a match object and store it in the database. The response will contain information about the object and whether the action was successful.
2)
The user asks for a list of matches
REQUEST
GET # /api/matches/curret
The response will be a JSON object containing a list of current matches.
RESPONSE
{
matches: [
{id: 1, teams:...}, ...
]
}
3)
(If push)
A user subscribes to a match
REQUEST
GET # /api/SOME_MATCH_ID/observe
The user will now be added as an observer for the match. Again, the response contains information about whether the action was successful or not.
4)
The administrator updates a score
REQUEST
UPDATE # /api/SOME_MATCH_ID
body: team1scored...
The score now gets update on the server (in memory/database) and the user will be notified about the updated score.
5)
The user gets the updated score
REQUEST
GET # /api/SOME_MATCH_ID
RESPONSE
... (Updated score in some way)
Say I want to develop a web application that will have registered users and will be registered as a twitter app (allowing users to give it permissions to view their timeline and post on their behalf). The sole function of the application will be to re-tweet tweets from users' timeline according to users' settings and desires.
I understand that the website for this app will use the common technologies like HTML, CSS and JS on the client-side. The server side (where the user defines what kind of tweets the application should retweet) will have to be coded in PHP/Python/Perl/... based on a DB MySQL/Postgre/...
What I don't understand, and would really appreciate your help with, is where the real "business logic" will be coded? For example, what technology should I use to code the function that will sit on my server: contacting Twitter server every 5 minutes, reading the timeline of every user I have, checking whether there are tweets worth retweeting (according to what the user has defined), and sending Tweeter the necessary commands to retweet the chosen tweets on behalf of my users.
All that will happen off-line for the user, and will be an on-going and cyclic process - but what technology should I use to code it?
Thanks!
I have heard about this API for PHP. It is actually the only one that I have heard of for PHP, though. I know that there are some good Python libraries out there, but I don't know about Perl.
I am actually working on a new API for C# (won't be a good fit for you, as you're clearly not using Windows Servers), and started building it while working on an enterprise web application that prompted several questions similar to your own.
Here is what you are going to have to do:
Before you start, you are going to have to get in touch with one of Twitter's data partners (I believe that you may contact Twitter for the reference)
The reason for this is that you are going to be requiring many more requests than you think
Twitter's time interval used for Twitter's recorded rate cap is 900 seconds (5 minutes)
With the general rate limit if you are querying a user's timeline only once every rate limit, you are limiting your number of visitors on your site to 300 at a time
Here's where it gets tricky - if every user makes one Tweet (meaning you send the Tweet - not rate limited - and then refresh the timeline - rate limited - so that they can see the updated tweet) you have now dropped your maximum number of active users at any given time to 150
Factor in the company's own timeline (-1 visitor), plus the number of visitors who leave their browsers open (now you need more logic, and you have to either kick them off or simply keep track of whose timeline you won't be refreshing), the number of users who make more than one tweet (-1 visitor for each Tweet), etc.
Moral of the story: contact one of their data partners and get yourself either unlimited requests, or at least a significant enough amount to accommodate your number of visitors/users (plus a bit of padding)
If you adhere to this advise, skip steps 2 and 3, otherwise, skip step 4
(Note: Steps 2 and 3 are only for rate-capped implementations) Using your desired language, make a service that runs on the server and makes the queries to Twitter
Based on the information that you gave, I suggest that you use Python to make this service
The service will run at all times and be on it's own clock to base the 5-minute intervals between the requests on
You will have to use a caching or a database system for storing the data
(Note: Steps 2 and 3 are only for rate-capped implementations) Add the necessary code to make a request to the service that you created for the data and perform these requests every 5 minutes
I suggest that the clock used for making these requests to the service be running a little bit behind the clock used for the service to account for instances of slow data transfer, etc.
You will also have to have to call some methods on the service for adding/removing users from the queue
(Note: Step 4 is only for unlimited request implementations) Forget about the service and simply include the request code directly in the page that the user is on.
The user's timeline will be updated based on when they visited the site or when their timeline was last refreshed (if a Tweet was made)
The only caveat to this implementation is that you will have to pay for the unlimited/larger data rate limit
I want to create a weather app for my android phone but now I got stuck on the backend part of the app.
I have found a weatherservice where I can, for free, get detailed information about a certain location through their webservice. But they have stated in their rules that I am not allowed to poll their service with a high frequency. So I thought that I could create a webservice on my own that retrieve weatherinformation from the weatherstation that I found and then make it available through my webservice so that my app only make calls to my service.
the communication will be like below
MyApp <--> MyWebService <--> commercial webservice
the android app talks to MyWebService. And my webservice talks to the commercial service.
So I want MyWebService to do to things.
retrieve information from the commercial webservice once every hour and update my database
handle requests from my androidApp
My problem is that I know to little about web application and web services. I don't really know what language to choose for the webservice.
PHP with soap or REST looks like a good candidate for the second task. But I can't find any sample on how to handle the first task. Is there any easy way to tell the server to run my script once every hour?
I have been looking a litle into C# as well which would suit me a litle bit more as I am more used to C#. But the same question arise here. How do I handle the second task?
This is something that I wanted to write for a long time, but I feel totaly lost here.
Doing things "once an hour" (or more generally, scheduling tasks) from a web-only application is tricky for a number of reasons. It is much better in general to use the built-in mechanism of the operating system to perform scheduled tasks (e.g. cron under Linux, or Scheduled Tasks under Windows), or to write a service/daemon process that handles the updates.
Having said that, there is a fairly straightforward way to meet your requirement. You can cache the result of the commercial web service in your web application tier, along with a timestamp of the last time you retrieved the information. When a web request comes into your web service from your app, first check the timestamp of the cache. If the timestamp is less than one hour old, just returned the cached weather data. If the timestamp is more than an hour, call the commercial web service directly from there, write the result and the current time into your cache, and return the data you just got to the app.
PHP is certainly well-suited to this kind of task. Detailed instructions on how to do that are beyond the scope of a Stack Overflow question. Google for PHP and caching, try out some examples, and ask detailed follow-up questions if you get stuck.