We’d like to share photos to SNS, ex. FB via the camera whose OS system is ThreadX RTOS.
But we cannot find any SDK resource for ThreadX RTOS system.
Could we have any chance to share phtots to FB via ThreadX RTOS system?
Facebook's API is based on structured HTTP calls, you could write code to interact with it in any language with a networking stack; the documentation should be applicable to any language you're using, though it will probably reference Facebook's PHP or Javascript SDK in the examples.
Your biggest problem will be authentication, which requires a web browser with internet access on the device for the user to log in and grant access to your application; if you can find a way to do that, you shouldn't have other problems with the API
ThreadX has another package called NetX which supports TCP/IP communication.
Please see,
For NetX,
https://rtos.com/solutions/netx/embedded-network/
NetX Duo (IP V4/v6),
https://rtos.com/solutions/netx-duo/embedded-network-stack/
Related
I'm plannig to do a chat app with djano and django-channels that will allow me to run te application asyncronous, I want to implement the spotify API for everyone in the room listen to some music, it is possible to do this in an async application?
This would be in theory possible yes. However, it looks like it would be in violation of the Spotify Developer Policy. (From Section III. Some prohibited applications - point 4):
Do not create any product or service which includes any non-interactive internet webcasting service. For example, you can’t create an application which plays content from a single source to several simultaneous listeners.
It may well be that it depends, on the finer details of what your application does. From what you've said though, (and having skimmed through their policies) I would definitely suspect such an app would be in violation of their policies.
It all depends on what the Spotify API allows and the implementation requirements to work with the API. Whether your app is synchronous or asynchronous should not really matter for this element, however, async is arguably better practice for the modern web.
You may want to have a look at the Spotify Web Playback SDK for playing tracks in your web browser: Spotify Web App SDK
We have a c++ client application that a user authenticates and connects to the server using its credential through the client. Is there any way to implement SSO module for it to communicate with OpenAM?
There is two possible way to implement this:
using the C agent SDK to perform authentication and do session management -> you may find that the C SDK isn't that pleasant and potentially too much tied to web servers in certain aspects. Also the C SDK uses the legacy OpenAM endpoints, which will potentially mean that in the future you will most likely need to adapt your code to use a newer version of the SDK that uses the REST interfaces
use the new REST APIs directly. The REST interfaces are still evolving though, hence they are subject of changes. In 12.0.0 there will be an API versioning solution though, which should mean that existing REST clients can remain to use the "old" version of the REST API.
I have a REST API that will be accessed from mobile clients and a web application. I would like to use oAuth for it. Not necessarily for the resource sharing aspects (it will just be for our application right now) but because of the standard it provides for how to tokenize and sign requests.
My questions:
Is this a sane use of oAuth?
There are quite a few posts on here discussing the issue of having to
store the client secrets on the mobile devices, but is that really an
issue in this case since I own the service too?
Is there any reason to give each client their own secret? This is normally used for access revoking, but again, I control the serivce and could just disable their user account.
Now I am creating an iOS application. I also implemented some web services. My requirement is : "The user should be able to call a web service API by Sending a Text Message(SMS)". After a lot of research I found out that there a provider called Clickatell(http://www.clickatell.com/). But I don't know how can I configure it? Please help me in configuring this. Or Is there any other APIs or SMS gateways providing this service?
Disclaimer, I do developer evangelism part time at Nexmo.
Here are a few SMS APIs that I've used (I've not really used Clickatell, but I've gone through the signup process, and the following APIs seem a lot simpler to use):
Nexmo
Twilio
Tropo
All three APIs are straight forward REST/HTTP APIs.
You can call the API directly from your mobile application, however, you should consider if you really want to then compile your API credentials into your application. It may be better to host a kind pf proxy that your application uses - here's some example code used as a verification service, but it's essentially the same concept: https://github.com/Nexmo/Verify
I would suggest to take a look at Mogreet's new Developer Web Site
Very easy to use REST/HTTP APIs and very powerful. It supports sending SMS/MMS with awesome quality for all media types.
I am newbie here and confused by few things
Some websites (twitter, foursquare, etc) provide API to third-party developer to call. are those APIs the web services that the sites provide?
Are those web sites themselves built on top of those public APIs/web services? theoretically is it possible?
Comparing the traditionally built website and the websites build on top of web service, pros and cons? are there any performance, scalability, etc differences?
Thanks in advance!
I'm sure somebody can give you a more exact answer but reading your question and applying my self-taught knowledge:
The simple technical definition of Web Services according to W3C:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
I like to think of web services as the interactive elements of a site that its customer base utilizes. For example, Twitter's web services include: tweeting, messages, hashtags, etc. Web services are what users get to DO or DATA passed back and forth.
A public web API provides means for developers to utilize the web services on their own site. For example, Twitter's API allows example.com site to utilize tweeting, messaging, hashtags, etc from within their own domain. An API is how developers get external access to web services to make apps using those services.
I have no idea about this question. I wouldn't do that. I would use the methods the public API exposes access to. But, I've never written my own API, let alone on the scale of Twitter or foursquare.
I hope this helps.
First of all, maybe you need some more info about what an API is: please take a look at the Wikipedia api page.
To answer to you questions (these are only general thoughts and not best practices):
An API, in this case, is a way that a developer uses to access a webservice, and it's not the service itself.
The websites you mention are not using their own APIs, as these APIs are meant for remote users (clients), and offer limited data sets, while the websites need maximum performance, access to the full database, and (almost) always use server-side code. The websites you mentioned, probably use other, server-side, high-performance APIs.
See the previous point: although it depends highly on which APIs you use, what you call "traditionally built websites" (that is, web applications using server-side APIs) can afford higher performance than websites totally built on top of remote APIs, because they do not depend on the bottleneck of the network connection (because, again usually, the web server and the database server either run on the same machine, or communicate faster than the client's browser and the server).
The reason that would make most people choose to develop a webapp the traditional way is that free APIs provide limited functionality (e.g. Google custom Search, limited to 100 reults).