I am approaching ethereum for the first time and I am reading the documentation. Can anyone explain the difference between Ethereum Web APIs (BlockCypher) and The Ethereum API as a service (infura)? https://ethereum.org/en/developers/docs/apis/backend/#available-libraries
There is no real difference. BlockCypher and Infura are just 3rd party companies which have created their own set of api endpoints which control access to the ethereum json rpc api.
The best thing to do would be to check the documentation of each one to ensure they are capable of what you aim to use it for.
You may find one api has more features than the other.
What exactly do you need it for?
Related
Kindly, can anyone differentiate between System api and Process api?
Please provide answer in Generic terms, as i am unable to find on internet.
A system api abstracts from an existing system. It talks to the system in the language of the system (e.g. SOAP, direct Java calls, SAP calls, etc.). To the outside world it offers a clean API (usually REST with http and json). When you do a good job implementing your system api, you can exchange your existing system with a different/new one without changing the api of your system api to the outside world: Just implement a new system api with different adapter logic.
A process api should talk REST on "both ends". It calls one or several system apis to do its job. The process api orchestrates different jobs.
When you need more information, do a search with "api led connectivity"
A System API is a layer you build on top of a system, which handles all system specific connection quirks and settings. It then exposes these resources and it's logic in a standard format (usualy REST but you're free to choose something else like SOAP) to the rest of your API's. Like Roger Butenuth states:
"When you do a good job implementing your system api, you can exchange
your existing system with a different/new one without changing the api
of your system api to the outside world: Just implement a new system
api with different adapter logic."
A process API is where you keep your logic and orchestration, it does not 'talk' to end systems directly but instead connects to system API's to get it's data.
A process API should idealy only talk REST on both sides and can aggegrate data from multiple systems.
An example of a complex process API would be an "items you've ordered" API which takes in a user id as it's input, then talks to the system API of a CRM system to get the id used by the "order history system API".
However this API might only return a list of orders without any article information besides an article id. So our Process API then enriches this list with Article information fetched from "article information system API" with the id from the list.
I know it's out of the scope of the question, but for the sake of completeness i'l shortly explain the third variant as well:
An Experience API can be seen as a doorway into your API network, every (type of) client has different information needs and can communicate in different protocols.
It is the Experience API's responsibility to provide ALL the information required by a client in a format they support.
This takes the responsibility away from a client to know where the information needs to be fetched from.
(Customer info from CRM, Order info from proprietary sys one, Article info from article DB)
This concept of design has as a bonus that if when for example, the mobile app your company is making, gets some new functionality which requires extra data.
You can update the "mobille app experience api", which would leave your "superexpensive IBM Experience api" unchanged. Cutting down on development costs as you don't need to implement any changes in your other api consumers which would be the case had you had only one api.
I think the main difference is where you are implementing business process and rules/logics.
System API, within the scope of your design, are atomic APIs which will be used to construct higher level API (experience APIs). Process API is the orchestration layer where you can use Mulesoft flows to implement business process or logic.
System APIs do the heavy lifting work of CRUD operations.
Process APIs focus on business logic
System API's are underlying all IT designs are center frameworks of records that are regularly not promptly accessible because of its many-sided quality and network concerns. APIs give a method for concealing that many-sided quality from the client while uncovering information and giving downstream protection from any interface changes or legitimization of those frameworks.
Process APIs exemplify the fundamental business forms that cooperate with source and target frameworks or channels through an arrangement of framework APIs. For instance, in a buy arrange process, there is some rationale that is regular crosswise over items, geologies and retail channels that can and ought to be refined into a solitary administration that would then be able to be called.
And you will get some more clarity from this article https://dzone.com/articles/api-the-backbone-of-the-software-industry-know-how
System API and Process API will be part of API led connectivity.
System API is like awrapper service to either a main data base or saas platform
Process API involves application logic to validate search or query parameters
I want to build an application where it is possible for one client to call another client using webRTC. I've started to look into webRTC providers and I've found Toxbox among others.
Is it possible, using TokBox OpenTok, for a client to actually make a call to another client (similar as a regular phone call)? From their docs and specifications it seems that it is only possible to create a "session" (a room in which participants meet and chat).
Am I missing something, or are they only providing sessions that people join/leave?
Twilio seem to offer what I need here,
but I find it strange that I cannot find something similar at Tokbox.
Thanks,
Muff
Yes it is possible.
You need to make the distinction between the type of API the platform exposes to what you can do with it.
While the OpenTok API is built around the concept of a room/session - you can easily use that concept to create a call. There are many openTok developers who do just that.
Twilio indeed offers the same capability - as are many others (a partial list can be found in this report - https://bloggeek.me/webrtc-paas-report/ - while the report is a paid one, the list is available on that page
The Yammer API is partially documented here.
https://developer.yammer.com/v1.0/docs/rest-api-rate-limits
I expect to find this endpoint documented
https://www.yammer.com/api/v1/groups.json
but it not documented.
I found it in this post
Yammer API - List of groups for each user
And it does work.
I assume that there are other useful endpoints as well.
Can someone point me to more complete documentation. Or is it possible to query the API for a list of endpoints?
The first link you list is in fact the full documentation. Groups.json is a working endpoint, but not a documented one. This means that Yammer does not promise to support this endpoint, and may decide to change it at any point, possibly breaking any code that relies upon it.
You can find lots of undocumented endpoints by running a toll such as Fiddler against the Yammer web interface, and lots of developers, myself included, develop solutions against these endpoints. We just have to remember, and make sure our clients understand, the implications of developing with these APIs.
Will there be an "activity" endpoint for us 3rd Party developers to use so we may build apps that have the same information as the "official" apps?
Even piecing together data from other endpoints we cannot build such a feature since there's no way for us to get checkin history for users other than "self". We can only get other users last checkin.
Thought I'd read some time ago that the website and official apps were just going to use the api so there must be some hidden/not public endpoints.
Just curious.
The official app does use the same endpoints exposed through the API, but the public API is only a subset of what the official app uses :) (e.g., we don't allow account creation)
Having said that, there's currently no "activity" endpoint we expose, nor will we likely expose one in the future. Sorry bout that!
Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.