Post Corona, Code for America Looks to Join Devs, Civic Techies and Gov Officials To Transform GovOps

Device Specific:

Scope:

Visual Composer API - Visual Composer Website Builder

Docs Home Page URL:

Supported Response Formats:

https://visualcomposer.com/terms-of-use/

Is This an Unofficial API?:

Is This a Hypermedia API?:

Restricted Access ( Requires Provider Approval ):

Type:

Product

Supported Request Formats:

https://visualcomposer.com/help/api/

Architectural Style:

Unspecified

Version:

1.0

Is the API Design/Description Non-Proprietary ?:

Yes

Other(not listed):

Version Status:

Recommended (active, supported)

Direction Selection:

Provider to Consumer

↧

Visual Composer

April 13, 2020, 1:10 pm

≫ Next: Codugh Pays Developers for Every API Call

≪ Previous: Visual Composer

API Endpoint:

https://visualcomposer.com/

API Description:

The Visual Composer API allows developing custom elements to build a website. An element is an independent component of the system that represents an HTML based block with the ability to output media and dynamic content. Download, Visual Composer, a web site builder for developers at <a href="https://visualcomposer.com/features/developers/">https://visualcomposer.com/features/developers/</a>

How is this API different ?:

SSL Support:

Yes

API Portal / Home Page:

Twitter URL:

https://twitter.com/VisualComposers

Interactive Console URL:

Primary Category:

Web Site Management

Secondary Categories:

Design

Device Specific:

Scope:

Visual Composer API - Visual Composer Website Builder

Docs Home Page URL:

Is This an Unofficial API?:

Is This a Hypermedia API?:

Restricted Access ( Requires Provider Approval ):

Type:

Product

Architectural Style:

Version:

-1

Description File URL (if public):

Is the API Design/Description Non-Proprietary ?:

Yes

Other(not listed):

Other Request Format:

Other(not listed):

Other Response Format:

Type of License if Non-Proprietary:

Version Status:

Recommended (active, supported)

Direction Selection:

Provider to Consumer

↧

Codugh Pays Developers for Every API Call

May 12, 2020, 12:50 pm

≫ Next: Node.js v14 Has Arrived With Some New API Features

≪ Previous: Visual Composer

Super Short Hed:

Codugh Pays Developers for Every API Call

Featured Graphic:

Primary Target Audience:

Primary Channel:

Primary category:

Secondary category:

Summary:

Codugh wants developers to directly earn money for their APIs. It's building a marketplace where developers publish APIs. As those APIs are used, regardless of integrated application, the API developer gets paid. Codugh has partnered with Bitcoin SV (BSV) to pay developers per call.

Codugh wants developers to directly earn money for the APIs they create. The company is building a marketplace where developers publish APIs. As those APIs are used, regardless of integrated application, the API developer gets paid. It's a pay per call model, and Codugh has partnered with Bitcoin SV (BSV) to make it happen.

BSV facilitates unlimited scaling and microtransactions, which makes it an ideal platform to roll out Codugh's marketplace. Developers can set their own rates, but it will likely be a few cents, or less, per call. Developers who have success on the platform will rely on thousands, if not millions, of microtransactions to build their compensation. In addition to getting paid in Bitcoin, developers can leverage other platform features including performance badges, ratings, and user feedback.

Getting started with Codugh is three simple steps for developers. First, developers need to create and deploy the API. Second, developers upload the API endpoints into the Codugh marketplace. Third, each time the API is called, the developer is paid in real-time.

Codugh has not let launched. For early access, sign up at the Codugh site. At the site, Codugh also addresses intellectual property rights, authentication, and other frequently asked questions.

Content type group:

Articles

Top Match Search Text:

Codugh Pays Developers for Every API Call

↧

Node.js v14 Has Arrived With Some New API Features

May 13, 2020, 11:40 pm

≫ Next: DEV

≪ Previous: Codugh Pays Developers for Every API Call

Super Short Hed:

Node.js v14 Has Arrived With Some New API Features

Featured Graphic:

Primary Target Audience:

Primary Channel:

Primary category:

Secondary category:

Application Development

Featured:

Yes

Summary:

Version 14 of Node.js was released on April 14, and it brings several new features, some experimental, which can be a benefit to API providers and consumers. Node.js relies on an internal JavaScript engine called V8 that recently released a new version that is now a part of Node.js 14.

Version 14 of Node.js (the server-side Javascript platform) was released on April 14, and it brings several new features, some experimental, that can be a benefit to API providers and consumers. Node.js relies on an internal JavaScript engine called V8 that's built by Google. V8 recently released a new version, 8.1, that also includes new features. This newest version is part of Node.js 14, and as such, those new features are available in Node.js as well. Let's explore some of these new features.

Optional Chaining and Nullish Coalescing

V8 version 8.1, and thus Node.js 14, includes a new JavaScript language feature called Optional Chaining. Although seemingly trivial, this feature is going to prove a huge benefit to API consumers. To understand what it is, let's first look at a situation where you would need it. When you call a web API, you typically use an SDK built for the API (usually offered by the API provider), or you'll use an HTTP library such as request.js, found at https://github.com/request/request. Some APIs provide a flexible response structure, meaning objects may or may not have the members you need.

For example, you might call an API that returns customer information like this:

{ 
    first: 'John', 
    last: 'Smith', 
    phone: '919-555-1212', 
    office: {
        primary: {
            address: '123 Main St',
            city: 'New York',
            state: 'NY',
            zip: '10010'
        },
        secondary: {
            address: '111 First Ave',
            city: 'Chicago',
            state: 'NY',
            zip: '60007'
        }
    }
}

This object contains an office object, that contains a primary member and a secondary member. If you need to access the zip of the secondary member, you can use code such as this:

console.log(obj.office.secondary.zip);

This only works, however, if all the members you're accessing actually exist. Suppose the API only returns a secondary object when the customer has a secondary office. If the entire secondary object is gone, trying to access its zip member will result in an exception, because the secondary object isn't even present:

TypeError: Cannot read property 'zip' of undefined

If you don't have an exception handler, your entire Node.js program will stop. Previously, the way around this is to pack your code with if statements. There are different approaches, but this is a simple one:

if (obj && obj.office && obj.office.secondary && obj.office.secondary.zip) {
    console.log(obj.office.secondary.zip);
}
else {
    // Handle the situation that the secondary office isn't present
}

With the new version, however, the V8 engine allows you to use optional chaining. Here's how you use it:

console.log(obj.office.secondary?.zip);

No "if" statement is needed. Notice the question mark after the word secondary. This tells node that you're not sure if the office object will contain an object called secondary, and if not, to just halt the processing of the expression and return undefined. So if the secondary object is present, the console.log will print out the zip like so:

And if the object isn't present, it will print out undefined:

undefined

You'll likely still need an "if" statement, but your code will be much simpler. For example, you might need to put the question mark in multiple places in the expression. Then you can try to store the zip in a variable, and then test if the variable contains undefined or not:

var zip = obj?.office?.secondary?.zip;
if (zip) {
    console.log(`The secondary office zip is ${zip}.`);
}
else {
    console.log('No secondary office zip code found.');
}

The advantage to putting the question mark after the initial obj is you don't need to first test if the request returned an object at all. Of course, you'll still need to handle errors appropriately; if the object comes back null because the customer doesn't exist, you'll want a separate error message from simply stating that no secondary office zip code was found. But in any case, your code will be simpler with fewer lines. And fewer lines of code means less chances for bugs.

Another new feature in V8 fits closely with optional chaining is called the nullish coalescing operator. Prior to the latest V8, if you wanted to provide a default value in an expression to use if a member doesn't exist, you could use the logical "OR" operator, like so:

console.log(obj.value || "empty");

This would print out obj.value, unless obj doesn't have a value member, in which case it would print out the word "empty". However, there's a flaw here. If obj.value is 0 or an empty string, "", this line of code will still print out the word "empty". That's because in logical OR expressions, the number 0, the empty string, the value null, and the value undefined all equate to a false value.

The newest V8 provides a new operator that you can use instead. It's called a nullish coalescing operator and it consists of two question marks. It behaves almost exactly like the above OR operator, except only the null and undefined values get passed through to the default value. So you can use this instead:

console.log(obj.value ?? "empty");

Now if the value is 0 or an empty string, you'll get back the respective value, 0 or empty string. Only if the value is null or undefined will you get the default value, in this case the word "empty".

Now go back to the optional chaining feature. The nullish coalescing operator can help you provide a default value, like so:

var custzip = obj.office.secondary?.zip ?? "No secondary zip code";
console.log(custzip);

Here, if the secondary object is present and it has a zip member, the custzip variable will receive the zip code. But if either the secondary object or zip member is missing, the expression to the left of ?? will give back undefined, and the ?? will transform that undefined into the string "No secondary zip code."

Async Local Storage

This next new feature is still in the experimental stage, which means you'll want to try it and test it out, but not use it in production. The feature is called async local storage, and can be a benefit especially to API providers.

The idea behind async local storage is to tie storage to a series of code sections that run asynchronously. If you've used HTTP frameworks for Node such as Express.js, you've likely used a sort of asynchronous local storage, because Express provides its own implementation that's not native to Node.

The idea is that you might have three functions that get called in sequence in response to a single web request in an API provider system. The first one might look up data based on the user making the HTTP request, and save it into a storage area. The second might do another database lookup, and the third might send the combined data back to the user. The tricky part is that another user on the web (or possibly thousands of users) might also be calling your web server at that same time. And each of the three functions needs its own separate storage areas for each request.

We're not talking about session storage here. We're talking about storage per HTTP request. But we still want the storage we're using to be unique among requests, but shared across all three functions.

There are already lots of examples on the web that claim to demonstrate how to use the local storage, but most of them are rather contrived and use setTimeout. Perhaps a better, more useful example would be one that uses the async.js library (found at https://caolan.github.io/async/v3/), and the MongoDB native driver (found at https://github.com/mongodb/node-mongodb-native) available through these npm calls:

npm install --save async
npm install --save mongodb

The following code is a modified version of the async local storage example found in the official docs at https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage. But instead of using a setImmediate, it does two actual database lookups. The code uses a common pattern where the database lookups take place inside async waterfall functions. But instead of storing the results of the database in a local variable, it stores the results in a store.

Here's the code:

// Load required modules
const http = require('http');
const { AsyncLocalStorage } = require('async_hooks');
const async = require('async');
const MongoClient = require('mongodb').MongoClient;
const asyncLocalStorage = new AsyncLocalStorage();

function getdata(cb) {
    // Connect to the mongo database server
    MongoClient.connect('mongodb://localhost:27017', function(err, client) {
        // Load the database
        const db = client.db('testdb1');
        // Start the sequence of functions, i.e. "waterfall"
        async.waterfall([
            function (wcb) {
                // Open the customers collection and get one customer
                const coll = db.collection('customers');
                coll.findOne({token:'1111'}, function(err,cust){
                    asyncLocalStorage.getStore().customer = cust;
                    wcb();
                });
            },
            function (wcb) {
                // Open the orders collection and get all
                // orders for this one customer. Convert it
                // to an array as well.
                const coll = db.collection('orders');
                coll.find({customer:
                  asyncLocalStorage.getStore().customer._id})
                  .toArray(function(err,orders){
                    asyncLocalStorage.getStore().orders = orders;
                    wcb();
                });
            }
        ], function() {
            // Final step, close the database and call
            // the callback function
            client.close();
            cb();
        });
    });    
}

// Keep an individual count of each time the
// store is created. Store it in the idSeq variable.
let idSeq = 0;
// Create the web server
http.createServer((req, res) => {
    // Create the store for this HTTP request
    var store = { id: idSeq++ };
    // We wrap the store in a call to "run".
    asyncLocalStorage.run(store, () => {
        // Call our getdata function
        getdata(function() {
            // Send the data back to the consumer
            res.end(JSON.stringify(asyncLocalStorage.getStore()));
        }, 1000);
    });
}).listen(3000);

This code creates a store with each incoming HTTP request by calling asyncLocalStorage.run. Remember, we're still not talking about sessions; the HTTP server is still sessionless. But the store works like a global variable accessible from any of the callbacks that are triggered from within the run call. And you could certainly do as we've done in the past, and simply pass an object around to all the calls, and fill its members accordingly, and send it out with a callback. But this local storage approach takes away the complexity of passing data around, and ensures that the store is always there whenever you need it. To grab it, you just call asyncLocalStorage.getStore().

You can see then how the waterfall functions grab the store anytime they need it. They do a database query and store the results in the store object. Then at the end of the request, the code calls res.end and sends the stringified JSON data back to the caller. Note, however, that I've hardcoded the customer token lookup to 1111. In a "real" application you would get that from a cookie that was likely created with a login, or if it's a REST call, from the URL making the call.

If you want to try this out yourself, here's a script to paste into MongoDB to initialize the data:

use testdb1;
db.customers.insert({ "_id" : ObjectId("5eab167ba24567257179fcbf"), "name" : "John Smith", "phone" : "9195551212", "token" : "1111" });
db.customers.insert({ "_id" : ObjectId("5eab1682a24567257179fcc0"), "name" : "Sally Jones", "phone" : "6165551212", "token" : "1112" });
db.orders.insert({ "_id" : ObjectId("5eab1b156d35168ded88f846"), "customer" : ObjectId("5eab167ba24567257179fcbf"), "sku" : "SKU123", "total" : 12.35 });
db.orders.insert({ "_id" : ObjectId("5eab1b1f6d35168ded88f847"), "customer" : ObjectId("5eab167ba24567257179fcbf"), "sku" : "SKU555", "total" : 25.5 });

Then when you run the server code, in another command prompt you can make multiple calls to the code with this:

curl localhost:3000/
curl localhost:3000/
curl localhost:3000/

With each run to curl, you will get back another object. Look at the id of the object and you'll see it's different each time.

Diagnostic Reports

Version 12 of Node had an experimental feature called Diagnostic Reports. With this new version 14, that feature is now stable, and no longer experimental. That means you're free to start using it in your production code.

Obtaining a diagnostic report is a simple matter of one function call. Save the following code to a file and run the file under node:

function test() {
    process.report.writeReport();
}
test();
console.log('Ready');

The line inside the test function is the single call, writeReport, which saves the diagnostic report to a file. The program continues to run, as you'll see by the line Ready being written to the console.

After you run this, you'll see a new file containing JSON. When you open it you can see a great deal of information, such as the version of Node that's running; information about the computer itself; a full stack trace for where the call to writeReport occurred in the code; full information on the JavaScript memory heap (much like what you can see in Chrome's debug tools); environment variables; and more.

This is only the surface of what's available for diagnostic reports. There are two excellent resources for learning about them; first is a Medium article and second is the official documentation.

Web Assembly

Another interesting feature in Node 14 is an implementation of WebAssembly System Interface (WASI). Like the async local storage, this is also an experimental feature. But if you're building high-performance apps, whether API providers or consumers, you might want to try this out. Node already has a reputation for being blindingly fast, but there's always room for improvement.

We don't have space here to teach you how to use WebAssembly, as it's an entire programming language that runs inside the V8 engine that's been likened to the idea of compiled Javascript. However, what follows is a very quick demonstration of it in action. Be sure to look at the official documentation at https://nodejs.org/api/wasi.html, and especially note the reminder at the bottom of the example that you have to provide some runtime arguments to Node to activate this feature.

First, here's a web assembly program, which I borrowed from this example. https://webassembly.github.io/wabt/demo/wat2wasm/.

(module
  (func (export "addTwo") (param i32 i32) (result i32)
    local.get 0
    local.get 1
    i32.add))

Save this in a file called simple.wat. This code module exports a function called addTwo, which takes two integers and returns the sum.

To compile this code, you'll need some tools that you can find at https://github.com/webassembly/wabt. Follow the steps for installing the tools and adding them to your path. Then you can compile the code like so:

wat2wasm simple.wat -o simple.wasm

This will create a binary Web Assembly file called simple.wasm. Finally, create a file called app.js with the following:

const fs = require('fs');
const { WASI } = require('wasi');
const wasi = new WASI({});
const importObject = { wasi_snapshot_preview1: wasi.wasiImport };

WebAssembly.compile(fs.readFileSync('./simple.wasm'))
.then(function(wasm) {
    WebAssembly.instantiate(wasm, importObject).then(function(instance)
    {
        var addTwo = instance.exports.addTwo;
        var test = addTwo(5,6);
        console.log(test);
    });
});

Run the code with these required command-line parameters:

node --experimental-wasi-unstable-preview1 --experimental-wasm-bigint app.js

This code will load the simple.wasm you built from the wat2wasm tool; compile the code; instantiate a WebAssembly instance with that code, and then save the compiled code into an object called instance. You can access the compiled code through the instance.exports object; in this case, the object has a member called addTwo, the same as the function name in the original WebAssembly code. This JavaScript code grabs that function and saves it into a local variable simply called addTwo. Then it calls the function just like it would any other JavaScript function, except this is compiled WebAssembly code. In this case, it passes 5 and 6, saves the result (11) in a variable called test, and prints out the variable.

Conclusion

Be sure to check out the official announcement from the Node JS team, here. Also check out the official documentation at https://nodejs.org/api/. Although some of these new features might seem trivial, such as optional chaining, they can be pretty useful in APIs, both for providers and consumers. Make sure you pay close attention to what's still considered "experimental" and don't use those features in production code. But practice with them, because they will likely become stable features in a future release of Node, hopefully sooner than later.

Content type group:

Articles

Top Match Search Text:

Node.js v14 Has Arrived With Some New API Features

↧

DEV

May 14, 2020, 12:45 pm

≫ Next: DEV

≪ Previous: Node.js v14 Has Arrived With Some New API Features

API Endpoint:

https://dev.to/api

API Description:

The DEV community is a platform where developers can share ideas, submit tutorials, and ask questions. The DEV API enables DEV's articles in third parties. Additionally, the API supports comment management, access to listings (classified ads), access to podcasts, and user management. API Key is implemented for authentication, and JSON for requests and responses.

SSL Support:

Yes

API Portal / Home Page:

https://docs.dev.to/api/

Twitter URL:

https://twitter.com/thepracticaldev

Developer Support URL:

https://dev.to/contact

Support Email Address:

yo@dev.to

Authentication Model:

Primary Category:

Secondary Categories:

Blogging

Social

Device Specific:

Scope:

Docs Home Page URL:

DEV API (beta)

Supported Response Formats:

Is This an Unofficial API?:

Is This a Hypermedia API?:

Restricted Access ( Requires Provider Approval ):

Yes

https://dev.to/terms

Type:

Supported Request Formats:

Architectural Style:

Version:

0.7.0

Description File URL (if public):

https://docs.dev.to/api/

Description File Type:

OAS 3.0 JSON

Is the API Design/Description Non-Proprietary ?:

Yes

Other(not listed):

Version Status:

Pre-release

Direction Selection:

Provider to Consumer

↧

DEV

May 14, 2020, 12:45 pm

≫ Next: Google Ending Support for JSON-RPC and Global HTTP Batch

≪ Previous: DEV

API Endpoint:

https://dev.to/api

API Description:

How is this API different ?:

SSL Support:

Yes

API Portal / Home Page:

https://docs.dev.to/api/

Twitter URL:

https://twitter.com/thepracticaldev

Developer Support URL:

https://dev.to/contact

Interactive Console URL:

Support Email Address:

yo@dev.to

Authentication Model:

Primary Category:

Secondary Categories:

Blogging

Device Specific:

Scope:

Docs Home Page URL:

DEV API (beta)

Supported Response Formats:

Is This an Unofficial API?:

Is This a Hypermedia API?:

Restricted Access ( Requires Provider Approval ):

Yes

Type:

Supported Request Formats:

Architectural Style:

https://github.com/christianezeani/panthera-jekyll

Version:

-1

Description File URL (if public):

Is the API Design/Description Non-Proprietary ?:

Yes

Other(not listed):

Other Request Format:

Other(not listed):

Other Response Format:

Type of License if Non-Proprietary:

Version Status:

Pre-release

Direction Selection:

Provider to Consumer

↧

Google Ending Support for JSON-RPC and Global HTTP Batch

May 15, 2020, 11:21 am

≫ Next: How to Empathetically Design APIs That Developers Will Love

≪ Previous: DEV

Super Short Hed:

Google Ending Support for JSON-RPC and Global HTTP Batch

Featured Graphic:

Primary Target Audience:

Primary Channel:

Primary category:

Secondary category:

Featured:

Yes

Summary:

Google first announced its intention to discontinue support for JSON-RPC protocol and Global HTTP Batch in its APIs in 2018. Its original timetable was to discontinue support in March of 2019. That timetable was extended, but the new deadline is fast approaching. The new date is August 12, 2020.

Starting in February, and running through August of this year, Google has scheduled downtime for both JSON-RPC and Global HTTP Batch to allow users to identify their systems that rely on these features. Google updates the scheduled downtime schedule from time to time. The most up to date schedule will always be posted to this blog post.

For developers looking to test if they rely on JSON-RPC, two options are available. First, send a request to https://www.googleapis.com/rpc. Alternatively, send a request to https://content.googleapis.com/rpc.

Regarding HTTP batch, developers forming homogenous batch requests using Google API Client Libraries, non-Google API client libraries, or no library should migrate. For more details on how to migrate away from these outdated features, follow instructions at Google's blog post announcement.

Content type group:

Articles

Top Match Search Text:

Google Ending Support for JSON-RPC and Global HTTP Batch

↧

How to Empathetically Design APIs That Developers Will Love

June 16, 2020, 1:40 pm

≫ Next: How to Install Microsoft's VS Code Source Code Editor On Mac or Linux

≪ Previous: Google Ending Support for JSON-RPC and Global HTTP Batch

Super Short Hed:

How to Empathetically Design APIs That Developers Will Love

Featured Graphic:

Primary Target Audience:

Primary Channel:

Primary category:

Secondary category:

Contributed Content:

Yes

Featured:

Yes

Summary:

Design is important in many aspects of development which is especially true for development that drives UX. We've learned that API design can have a profound impact on user interfaces and thus user experiences. Poorly designed APIs can lead to awkward, unnatural, or inefficient workflows.

Design is important in many aspects of development which is especially true for development that drives user experience. We've learned that API design can have a profound impact on user interfaces and thus user experiences. Poorly designed APIs can lead to awkward, unnatural or inefficient workflows within a user's experience while a well-designed API can mitigate these issues or at least make it clear to developers what all is technically possible. Ultimately, user interfaces are a representation of the underlying API.

Here are five design, implementation, performance and security best practices to keep in mind when producing APIs.

Best Practice: Make your API a Priority

APIs should be designed and developed with simplicity, consistency and ease of use in mind. Accomplishing these things may be easy in a silo but the consumer's view may be drastically different since their needs or wants were likely not taken into account. It's always important to design and iterate closely with consumers and/or clients before producing any long-term implementation. The best way to do this is by practicing API-First Design which is a design methodology focused on collaboration with stakeholders. Continuing with the alternative may result in an API that conforms to the existing system or simply serves as a conduit to the underlying database which will almost always ignore the client's workflows. A great analogy exists in the construction world – you wouldn't build a house and then draft blueprints.

Additionally, by leading with API design, it's possible to identify API specification format and tooling from the beginning. The API specification should be described in an established format such as OpenAPI, API Blueprint or RAML. An established format is likely to have sufficient tooling that clients are familiar with like Apiary, Redocly or Swagger Hub. Depending on the time gap between API Design and client development, it may be appropriate to consider mocking functionality which most established tools will have. Mocking is a good way to give prospective consumers a tour of example data while the implementation is built out.

Best Practice: Structure with Resource Oriented Design

There is a very common architectural style known as REST that has become the defacto standard on API's for some time now. APIs that are developed using REST architecture are said to be RESTful. In general, REST provides important and well-known architectural constraints but lacks concrete guidance on authoring API's. There is an expanded architectural style known as Resource Oriented Design, satisfying all the constraints of REST, that serves as a good API design reference. If we're to compare REST to SQL, Resource Oriented Design provides similar normalization properties to REST as 2NF and 3NF do for SQL. Here are a few constraints to adhere to:

The API URIs should be modeled as a resource hierarchy where each node is a resource or collection resource
- Resource– a representation of some entity in the underlying application e.g. /todo-lists/1, /todo-lists/1/items/1
- Collection– a list of Resources all of the same type e.g. /todo-lists, /todo-lists/1/items
The URI path– resource path - should uniquely identify a resource e.g. /todo-lists/1, /todo-lists/56
Actions should be handled by HTTP Methods

Following these constraints where practical will lead to a normalized API that's consistent and predictable. Also, by leaving actionable verbiage out of URIs, it's easier to ensure that every resource path is a representation of some entity. This is why verbs are frowned upon for RESTful API URIs as they are likely not a representation of some underlying entity. For example, /activate is likely not a resource.

As far as any data resources themselves, there is no universally accepted answer on the format used to represent them. JSON is widely adopted and understood by the majority of platforms. However, XML or other formats may serve consumers just as well or better in certain situations. The key thing is to represent resources in a way that is quick and easy for consumers to understand.

Representing resources in this fashion enables them to "speak" for themselves, known as self-descriptive resources. Self-descriptive resources that are documented using established tooling and open standards will build a sense of trust with the consumer. Ultimately, consumers should buy-in to what the API is selling without additional "fluff" material.

Best Practice: Semantics with HTTP and REST

In order to make an API come to life, it needs to be actionable especially since it will likely be used to inform a client's user interface – the buttons need to do something. Actions, in the context of REST, should be fulfilled by HTTP methods each with an intended purpose which is described here:

GET– query/search for resources, expected to be idempotent and thus cacheable
POST– most flexible REST semantic, any non-idempotent actions excluding deletes should be handled by this method
PUT– used to modify entire resources, yet still expected to be idempotent
PATCH– used to make partial modifications to resources, yet still expected to be idempotent
DELETE– removes a resource from the API, should be idempotent from the caller's view

Additionally, the result of each action should be returned to the client with a proper status code as defined by the HTTP standard. Your API doesn't need to support all of the standard codes. But it can support more than you think. Here are some common statuses that will likely be required on any API project:

Successful response (200 – 399)
- 200– responses with a body for everything besides a creation action
- 201– responses for creation actions
- 202– responses for a long running process
- 204– responses that don't require a body
Client errors (400 – 499)
- 400– invalid or bad request, appropriate for syntactic errors
- 401– unauthenticated request due to missing, invalid or expired credentials
- 403– insufficient permissions (e.g. wrong Oauth scope, requires admin privileges)
- 404– resource not found (e.g. represented entity does not exist in database)
- 409– resource conflict (e.g. resource already exists)
- 422– request is syntactically valid but not semantically valid
Server errors (500 – 599)
- 500– classic internal or unknown errors for modeling exceptional/unrecoverable errors, sensitive errors or errors that can't be elaborated on
- 501– method not implemented
- 503– server unavailable
- 504– timeout

For clarity, an idempotent HTTP method can be called many times with the same outcome. Consumers should be able to understand the information, relationships and operations an API is providing by the resources and methods on them alone. For example, a GET method that creates, or a PUT method that deletes a resource will lead to an unpredictable API fraught with unexpected side-effects. Proper HTTP method and status codes, which naturally includes constraints such as idempotence, used in conjunction with self-described resources are nothing more than factual representations of the underlying business domain.

Best Practice: Maintaining Performance at the API Layer

Building a fast-performing service requires careful thought and design, often across multiple technical boundaries. The list of things to consider for performance can range from proper use of concurrency in the application on down to adequate database indexing. It just depends on the requirements and needs of the business. The API can uphold performance characteristics of the underlying system in multiple ways, here's some to consider:

Asynchronous Server Code– Resources that are an aggregate of multiple independent data sources can be built by the result of multiple async execution results.
Non-blocking Implementation– APIs that access cold I/O, are CPU intensive or just naturally slow should return with a 202 whilst processing and instruct the client where to get the result. Websockets and callbacks may be appropriate in certain situations as well.
Caching– Resources that change relatively slowly can be cached. Idempotent GET requests are the low-hanging fruit. Service level caching may suffice but a content delivery network (CDN) may be needed depending on load.
Paging– Collection resources should be outfitted with paging controls for the client to limit results
Statelessness– Keeping track of state across requests can be complex and time consuming for the server. Ideally, state should be managed by the client and passed to the server. This applies to authentication/authorization as well. Credentials should be passed on each request. JSON Web Token (JWT) is a good option.

These considerations will go a long way towards meeting satisfactory performance metrics set by the business. Usually, business satisfaction is going to be directly tied to the satisfaction of its consumers. There has been plenty of research to show that a consumer's user experience is tied to the response time of a page. Network latency plays a big factor in page load time so it's important to reduce this time as much as possible. A good rule of thumb is to keep API response time between 150 and 300 milliseconds which is the range for average human reaction time.

Best Practice: Securing your API

Personal and financial information is prevalent on the internet today. It has always been important to safeguard this information. However, there have been many notorious data breaches in recent times that bump security considerations from just another thing to project non-starters without them.

There are two good rules of thumbs when it comes to API security; don't embarrass yourself and don't reinvent the wheel. It's best to leverage open standards such as OAuth or OpenID which both cover most authentication flows. It's also advisable to delegate identity matters to purpose-built identity providers such as Auth0, Firebase, or Okta. Security is a hard thing to get right and the aforementioned vendors have solved this challenge plus gone the extra mile or two. Regardless of the standard and/or provider used, it's always important to apply proper access controls to API resources. Resources that are sensitive should be locked down with appropriate credentials and a 401 should be returned when these credentials are not provided. In cases where a given user does not have adequate privileges to a resource, a 403 should be returned.

The best practices highlighted above are established practices in the industry that should help with any API project. By taking an API-First approach, you will be on the right path to fostering trust with your consumers and stakeholders. Practicing established REST structure and semantics as well as proper security will be huge contributing factors to your success. Maintaining performance will keep consumers and customers coming back for more. Ultimately, API design is part art and part science. Each API will be different and there may be some pragmatic decisions to be made. However, it's critical to not stray too far off the beaten path. It's important to remember that your data and information is what your consumers and customers are truly seeking, not your radical new API design. Following these best practices will get this information to your all-important customers while keeping your consumers informed all along the way.

Content type group:

Articles

Top Match Search Text:

How to Empathetically Design APIs That Developers Will Love

↧

How to Install Microsoft's VS Code Source Code Editor On Mac or Linux

July 1, 2020, 12:28 pm

≫ Next: Panthera-Jekyll

≪ Previous: How to Empathetically Design APIs That Developers Will Love

Super Short Hed:

How to Install Microsoft's VS Code Source Code Editor On Mac or Linux

Primary Target Audience:

Primary Channel:

Primary category:

Product:

Since its introduction, Visual Studio Code, often called simply "VS Code", has quickly moved to the top of editor choices by programmers. It's easily one of the most configurable, developer-friendly editors available. Even though it's created by Microsoft, Linux and Mac users have embraced it as well. It's fully open-source, and free, and all of the source code for it is available on GitHub. The editor runs inside a framework called Electron, which is basically a sandboxed version of the Chrome browser. As such, most of the editor's own code is written in JavaScript. The editor is highly extensible, providing thousands of official and community-built extensions supporting different themes, syntax highlighting for nearly every language imaginable, editing extensions, code snippets, most source code control systems, and more. (for version control, Git is supported out-of-the-box.) Developers are encouraged to create their own extensions and share them with the community through the official Extensions Marketplace.

Installing on Linux

There are several ways you can install VS Code on Linux, depending on your distribution.

Installing on Debian and Ubuntu

For Debian and Ubuntu, don't try to use the apt package manager. Instead, follow these instructions.

First, go over to the VS Code Download Page and download the .deb file.

Open up a terminal or shell prompt. Switch to the directory containing your downloads (typically ~/Downloads, which will be the Downloads directory in your home directory).

cd ~/Downloads

Display a list of the directory's contents and check for the name of the file you downloaded:

ls -ltr

The file should be the last one listed, and the filename will start with "code_" and end with ".deb."

The next step requires superuser privileges. To establish your username as a superuser, you'll need to log in as an existing superuser with "root" privileges. Typically, the username is "su" (for "superuser") or "root" and the password is one that you established when you first installed Debian. Once you've logged in as a user with root privileges,run this command:

usermod -aG sudo <username>

replacing <username> with your actual username. For example,

Usermod -aG sudo jeffc

Now, install the .deb file using this command at the shell prompt:

sudo dpkg -i filename

where you replace filename with the name you discovered above.

After that you can delete the .deb file you had downloaded by using the remove command:

rm <filename>

Now you can skip to the section in this article called "Testing it Out."

Technical Note: Although you can use VS Code without knowing this, you might be interested to know that the VS Code installer updates your system's package installer by adding an entry for Microsoft's package repository. Henceforth, VS Code will automatically update itself behind the scenes using your package installer.

Installing on Red Hat, Fedora, SUSE, CentOS

For these other distributions, you can use the package manager by following these steps. First, open up the terminal. (For example, if your distribution has Gnome, you can click the Activities menu, and then search for Terminal.)

As with Debian, you'll need superuser privileges. If you don't already have them, log in as an existing user with root privileges (same as noted in the Debian section above) and run the following command:

usermod -aG wheel <username>

replacing <username> with your actual username. (On these distributions, the "wheel" group has access to sudo privileges, hence the word "wheel" in the command.)

Next, paste the following command into the terminal:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

This will import the key file for Microsoft's repository. Then paste and run this command at the shell prompt (make sure you get all the lines, as it's a single command):

sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc"> /etc/yum.repos.d/vscode.repo'

Next paste and run this command, which will update yum's cache:

sudo dnf check-update

And finally, paste the following line, which will install VS Code:

sudo dnf install code

Now you can skip ahead to the section in this article called "Testing it Out."

Installing on Mac

The first step is to download the latest version of VS Code (don't use the Homebrew package manager). Go here and click the Mac version. This will download a .zip file. Click the downloaded file at the bottom of your browser (or open the browser's downloads list and click the .zip file in there.) The Mac's archive utility will open and automatically unzip the file. The unzipped file will be called "Visual Studio Code" and will appear in the Finder in the same directory as the .zip file (likely your Downloads directory). While in Finder, drag that file to the left, into the Applications folder. Now VS Code is installed. However, the path isn't set yet. Normally this is fine, but you'll likely want to open VS Code from the command line in Mac's Terminal application. Fortunately, VS Code includes a macro built right into it that will set the path for you. We'll do that next.

Go ahead and open VS Code by double-clicking its filename in the Applications folder. (The first time you'll see a warning that it was downloaded from the Internet. No problem, just click the Open button that's in the warning box.)

After VS Code opens, click the View menu, and choose Command Palette. (If you like hotkeys, you can instead hold down both Command and Shift, and then press P.) You'll see a text box appear at the top of the screen; this is the Command Palette.

Start typing the words "Shell Command" and you'll see a dropdown list of commands that start with that. Find the one (it's probably first) called "Shell Command: Install 'code' command in PATH." Click it.

In the lower-right corner you'll see a message:

Shell command 'code' successfully installed in PATH.

You're good to go! Go ahead and exit VS Code by clicking the Code menu, and then choose Quit Visual Studio Code.

Now open a terminal window. You can use the built-in Terminal program found inside the Mac's Utilities folder (which itself is in the Applications folder), or if you have a favorite one (such as iTerm2) you can use that instead. Then you're ready for the next step, "Testing it Out."

Testing it Out

Now you can test it out. At the shell or Terminal prompt, simply type:

code .

The "." tells VS Code to launch in the current directory. If you like, you can omit it and VS Code will launch in a default directory or the directory you last ran it in. Or you can specify a complete path, e.g.:

code /home/<username>/develop

Note for the bash experts: The "code" command is just a launcher. After using it to launch VS Code, you're immediately returned to the shell prompt. (You don't need to run it in the background with an & after it.)

Here are some quick observations. The code editor panel takes up most of the screen, as you would expect.

On the left is a pane called the Explorer, which includes quick access to your files. The top is a list of all the currently opened files. (If you don't want that there, you can collapse it by pressing the drop-down arrow to the left of the words "OPEN EDITORS".) Under that is a project tree. For more information on using VS Code and finding your way around, check out the official tutorials, found here.

Setting Configuration Options

Here at ProgrammableWeb, we're building a large set of tutorials that will all use a common set of configurations. To make this as simple as possible, we're going to have a root development directory under which you can save your projects. Because of the number of projects, we suggest opening your code editor so that it points to the current project directory (whatever project you're working on at the time), rather than the root of all the projects. We're also going to use a standard set of configurations and plugins for the editors.

Visual Studio Code has a huge array of options and you have a couple of different ways to control them. First, there's a settings page that lists common settings and places for you to enter in the settings, as shown in the following image. Behind the scenes, however, VS Code stores your settings in a JSON file that you're free to manually edit. What's cool here is that you can add custom configurations in this file that aren't present in the main settings page, and you'll still be able to use the main settings page. It's not strictly one or the other.

To open the main settings page, Start VS Code and do one of the following:

Click File -> Preferences -> Settings
Click the Gear (found in the lower left) -> Settings
Hold down Ctrl and press the comma

You should see the settings page open in VS Code's code editor area, as shown here.

The settings page in VS Code's code editor area

To close the settings page, simply click the close button on the tab at the top.

Note: VS Code allows you to include optional settings on a per-project basis. We're not going to use this feature here at ProgrammableWeb; however, if you want to try it out you can read up on it here.

Tabs vs Spaces
Indenting sub-sections of code such as the internals of an if-then-else statement or a do-while loop is an important habit for ease of readability. Not just for you, but for others that may have to view your code later. Like other code editors, VS Code has an indentation feature. Although this is a hotly debated topic, we're going to set our indentations to spaces instead of tabs for one simple reason: Spaces work better for copying and pasting code from our web pages into the editors. (You are welcome to reformat to tabs afterward if you prefer.) We're going to use four spaces to allow for easier reading of our code.

Language caveat: Unlike most other languages, Python relies on indentation levels and is picky about consistency between spaces and tabs. If you choose to convert any python code from spaces to tabs, you must make sure you do it for the entire file. Otherwise you'll get errors as soon as you run the program.

To set the indentation to spaces, look at the status bar at the bottom of the VS Code window; you'll see the words "Tab Size" or "Spaces" followed by a number. "Tab Size" means you're set up to indent using tabs; Spaces means you're set up to indent using spaces. The number you see is the size of the indentation. If you already see "Spaces: 4" then you're good to go. Otherwise, click "Tab Size" or "Spaces", and a popup will open whereby you can configure the tabs, spaces, and indentation size, as shown below.

Click "Indent Using Spaces" to set your preference to spaces. Next, a similar popup will appear with a list of numbers; choose 4. You can then convert the currently-open file if you like by again clicking either Tab Size or Spaces, and then click "Convert Indentation to Spaces."

Fonts and Sizes
This is up to you, as we all have a different vision and visual needs. VS Code lets you choose the fonts and sizes you prefer; we'll show you how here. Note, however, that because VS Code technically runs inside its own Chromium-based browser, you can set the zoom level, just like in Chrome. This means you use both approaches to get the look and feel to your liking. (Try this: With VS Code open, hold down Ctrl and type a + key, which might require pressing Shift depending on which + key you use. You'll see the entire app zoom just like inside a browser. Reverse it by pressing Ctrl and the minus key.)

To set the font family and font sizes, open up the settings, and on the left of the Settings pane, expand Text Editor; under that, click on Font, as shown here:

Unfortunately, the font family name is one area where VS Code isn't particularly user-friendly. The issue is that VS Code runs inside a browser, and as such uses HTML/CSS syntax for font family names. HTML/CSS font families are typically lists of font names surrounded by single quotes (when the font name has spaces), with commas between the font names. The browser starts from the left and goes through the list until it finds the first font that exists on the system.

There's no dropdown list or picker of any kind. You just have to know what fonts are available on your system, and you can type them in here. Fonts on Linux-based systems are usually in /usr/share/fonts (and subdirectories under that) or /usr/local/share/fonts. On the Mac, hold down the Command key and press Space; in the search box that opens type Font. Find "Font Book" in the results list and click it; the Font Book app will open to show you your fonts.

The size is more straightforward. Under Font Size simply type the size of the font you want in the editor.

Recommended Extensions

Our tutorials make use of several languages, and as such, you'll need the plugins to support these languages. By default, VS Code supports all of the languages we're using; however, the VS Code marketplace includes many free extensions that offer additional functionality for these languages, such as extra syntax highlighting and navigation, code linting, and more.

You can also access the marketplace by simply searching inside VS Code. To do so, do one of the following:

Click File -> Preferences -> Extensions
Click the Gear (found in the lower left) -> Extensions
Hold down Ctrl and Shift and press X

On the left side you'll see a list of extensions with a search box at the top, as shown below.

Try typing "C#". (You don't need to press enter.) Below that, in the left pane, you'll see a huge list of free extensions, some built by Microsoft and its partners, and some built by the community members. To see details of an extension, click on it, and a full-page description will open in the editor pane of VS Code. There, you can find user reviews (which we encourage you to read and consider) and the number of people who installed it (a good indicator of the quality of the extension; some have several million downloads, which suggests a strong approval). The better extensions will also include full instructions on their detail pages on how to use the extension. You can install an extension by clicking the little green "Install" button by the extension's title in the left pane, or by clicking the green Install button at the top of the detail page.

Important: Many extensions require you to restart VS Code after installing them. The green Install button will be replaced by a blue button with the words "Reload Required." You can click that button to restart VS Code. (All your existing editor windows will remain open.)

You can also install extensions right from the Marketplace page in the browser. Search for an extension, click on it to open its details page, click the "Install" button; your browser will download the extension and open it in VS Code, where it will be installed.

To remove an extension, the green Install button in VS Code gets replaced by a gear icon. Click it for a menu, and in that menu click "Uninstall." Then you'll see the familiar blue "Reload Required" button that you'll want to click.

Here are the extensions we recommend you install, listed by language, along with instructions on how to install them. You can install all of these, or only those for the languages you prefer. These extensions offer syntax highlighting, popups for suggestions as you're typing (known as Intellisense), and more. Each extension includes documentation when you open the details page showing all the features the extension provides.

Java: There are many Java extensions available; we recommend browsing the list by simply searching the Marketplace for "Java." At the very least, we encourage you to install two that Microsoft created, building on work by Red Hat. One is a full Java extension pack, found here, and the other is an integrated debugger, found here.

Node.js and JavaScript: VS Code by default has strong support for node.js and therefore JavaScript (which is the language of node.js). As such, we don't ask you to install any particular node.js extensions. (However, the community has built several that you are welcome to explore; simply type "node" into the Marketplace search box.)

TypeScript: As TypeScript was invented by Microsoft, VS Code also has strong native support. Note that there is, however, an official extension built by Microsoft called JavaScript and TypeScript Nightly. The purpose of this extension is to allow you to stay on top of the nightly updates to the TypeScript language. We only recommend installing this if you're a very serious TypeScript developer who wants to stay on the bleeding edge.

Python: Microsoft's official Python extension can be found here. Important for Mac: If you're a Mac user, you need to install a separate version of Python from the one that ships with MacOS. You can find the details here. (You're still free to use the version that ships with Mac; however, the plugin won't integrate with that version.)

C#: Microsoft has partnered with another company called OmniSharp to create the official C# extension. You can find it here.

Go (also known as golang): The official maintainers of the Go language (who work at Google) have built a VS Code extension for Go, which you can find here.

PHP: There isn't an official PHP extension, but there are several that millions of people have installed. For additional Intellisense features, go here. For PHP debugging features, install this extension.

Dart: There is no official Dart extension by either Microsoft or the Dart language team; however, there is an extension built by community members that has wide support, with over 1.5 million downloads. We therefore recommend this plugin.

C++: Microsoft's official C++ extension can be found here. This extension supports many different C++ compilers, not just Microsoft's. Specifically, for Linux, the support is for GNU Compiler Collection (gcc), and for MacOS the support is for Clang (which is included with the XCode IDE for Mac).

Rust: The official Rust language maintainers created an extension for Rust.

Ruby: Although we don't use Ruby often here at ProgrammableWeb, if you're into it, we recommend this extension. Please pay close attention to the instructions regarding enabling the language server.

SQL: There are many SQL database server extensions available. Microsoft has an official one for SQL Server and one for PostgreSQL. There is limited support for other servers (such as MySQL or Oracle), but by default, VS Code provides syntax highlighting for SQL files.

Other languages: This list is all the languages we use (or intend to use) in ProgrammableWeb's tutorials. But there's an extension for nearly any programming language that exists. For example, if you use Ada, there's an extension for that. Or Fortran, or even COBOL. If you have a favorite language not listed here, enter it in the Marketplace search box and there will likely be an extension for it. (And if not, you can build one.)

Launching the Integrated Terminal

Visual Studio Code includes an integrated terminal, allowing you to run shell commands right from within VS Code. The terminal works the same way as any other terminal; it includes a prompt that shows you your current directory. You can type all the usual bash commands (such as "ls" and "cd") as well as git commands if you're using git. You can learn more about it here. The terminal opens below the code editor as shown below.

To create a new terminal, do one of the following:

Click the Terminal menu -> New Terminal
Click the Terminal menu -> New Terminal
Press Ctrl+Shift+` (that's the back-tick character, usually to the left of the 1 key).

Optional: Integrating with git

Git is by the most used source code control software right now. We have decided to use git for our source code control, in conjunction with the website GitHub, which hosts code that's stored in git. You are not required to use git to use our samples; you can even download the samples as .zip files from our respective GitHub project pages and not use git at all. But if you choose to use git, you can easily submit suggestions for improvements to our code.

By default, VS Code comes with full git integration. As such, we do not recommend downloading any additional extensions to use our sample code. Note, however, that we typically do not recommend only trying to use git from within VS Code. Our reasoning is that most developer teams typically still use the command-line version of git, and many tasks are, quite frankly, a bit more intuitive to use at the command line rather than inside VS Code. Therefore we're taking a two-pronged approach to git:

When you're editing code that is inside a git repo, note the letters that appear beside your files in the Explorer as you add and modify files (see the screenshot below). The files that are untracked (i.e. not added to the repo) have a letter U to the right of them. Files that are tracked and you've changed get an M (for "modified") next to them. Files that are tracked by git and haven't been modified get no icon.
When you need to do any git work (e.g. create branches, add and commit files), we recommend using the command-line. (You're welcome to use either the integrated terminal for its ease of access, or you can do it in an OS shell such as bash.)

Our future projects here at ProgrammableWeb will have freely-available repos on Github. (And we welcome pull requests with suggested changes; we're making this a community-driven project.)

Summary:

Since introduction, Visual Studio Code, often called simply "VS Code", has quickly moved to the top of editor choices by programmers. It's easily one of the most configurable, developer-friendly editors available. Even though it's created by Microsoft, Linux and Mac users have embraced it as well.

Content type group:

Articles

Top Match Search Text:

How to Install Microsoft's VS Code Source Code Editor On Mac or Linux

Includes Source Code:

↧

Panthera-Jekyll

July 13, 2020, 11:33 am

≫ Next: Cloudflare Introduces Cloudflare Workers Unbound

≪ Previous: How to Install Microsoft's VS Code Source Code Editor On Mac or Linux

A quick and simple responsive developer portfolio theme for jekyll sites and GitHub Pages.

RubyGems

URL:

Image:

Mashup/App Type:

Web

Deadpool:

Primary Category:

Profiles

Secondary Category:

https://www.prompty.io/docs/api/

↧

Cloudflare Introduces Cloudflare Workers Unbound

July 27, 2020, 10:36 am

≫ Next: Prompty Server

≪ Previous: Panthera-Jekyll

Primary Target Audience:

Primary Channel:

Primary category:

Secondary category:

Summary:

Cloudflare announced Cloudflare Workers Unbound. Workers Unbound is a serverless platform for developers with a specific focus on flexibility, performance, security, ease of use, and pricing. Users can run complicated workloads across the Cloudflare network and pay only for what's used.

Cloudflare has announced Cloudflare Workers Unbound. Workers Unbound is a serverless platform for developers with a specific focus on flexibility, performance, security, ease of use, and pricing. With Workers Unbound, users can run complicated workloads across the Cloudflare network and pay only for what's used.

“I challenged our team to build a platform that didn't just compete with niche edge computing solutions, but would provide developers the fastest, most secure, most flexible, and most cost-effective general-purpose serverless offering — period," Matthew Prince, Cloudflare co-founder, and CEO, commented in a press release. "I'm incredibly proud of Cloudflare Workers Unbound and can't wait to see what developers will build with it.”

Cloudflare Workers Unbound is the next progression beyond Cloudflare Workers, which came out in 2017. The company pitches Workers Unbound as a platform that serves more use cases with more flexibility and better cost. Specific benefits the company points to include:

Limitless: Limited CPU restraints and only pay for what you use.
Cost-Effective: Very competitive pricing when compared to the industry
No Hidden Fees
No Cold Starts: Out of the box support for 0 nanosecond cold start times.
Unthrottled CPU: Isolated architecture lets Cloudflare run CPUs unthrottled so users can get more done per second of compute time.
Fast Globally: Workloads run across the Cloudflare network, spanning more than 200 cities in more than 100 countries, reducing average network latency for users everywhere in the world.
Instant Updates: Developers can update their code and have it live globally in 15 seconds.
Broad Language Support: JavaScript, C, C++, Python, Go, Rust, Scala, Kotlin, and even COBOL.
Automatic Scaling: Cloudflare Workers Unbound automatically scale to meet demand without developers needing to spinning up new instances.
Robust Debugging Tools: Simplified debugging and diagnosing problems.
Secure By Design: Built to withstand the latest security threats, including sophisticated timing attacks, and was reviewed by the team that discovered the Spectre class of vulnerabilities.

Cloudflare Workers will now be known as Cloudflare Workers Bundled. Cloudflare Workers Unbound is currently in private beta. Those interested can learn more here.

Content type group:

Articles

API RoundUp:

↧

Prompty Server

July 23, 2020, 12:14 am

≫ Next: Prompty Server

≪ Previous: Cloudflare Introduces Cloudflare Workers Unbound

API Endpoint:

https://app.prompty.io/api/

API Description:

The Prompty Server API enables developers to send web notifications using HTTP POST methods. JSON formatted payloads are required. Prompty offers tools to engage subscribers via automatic welcome notifications. Prompty supports notification reports to determine performance, and to see how many people received the notification, who read it, and who clicked on it.

SSL Support:

Yes

API Portal / Home Page:

Developer Support URL:

https://www.prompty.io/contact-us/

Authentication Model:

Primary Category:

Notifications

Secondary Categories:

Announcements

Application Development

Device Specific:

Scope:

Server API - Prompty - Web Push Notifications for SaaS Companies

Docs Home Page URL:

Supported Response Formats:

Is This an Unofficial API?:

Is This a Hypermedia API?:

Restricted Access ( Requires Provider Approval ):

Yes

Type:

Supported Request Formats:

Architectural Style:

https://www.prompty.io/docs/api/

Version:

1.0

Is the API Design/Description Non-Proprietary ?:

Other(not listed):

Version Status:

Recommended (active, supported)

Direction Selection:

Provider to Consumer

↧

Prompty Server

July 23, 2020, 12:14 am

≫ Next: Facebook Introduces v8.0 of Graph and Marketing APIs

≪ Previous: Prompty Server

API Endpoint:

https://app.prompty.io/api/

API Description:

This API allows users to send notifications as well as retrieve other useful information, such as subscriber data and stats, from the Prompty web push notification service.

How is this API different ?:

This is the official API for the Prompty web push notification service.

SSL Support:

Yes

API Portal / Home Page:

Developer Support URL:

https://www.prompty.io/contact-us/

Interactive Console URL:

Authentication Model:

Primary Category:

Notifications

Secondary Categories:

Announcements

Application Development

Device Specific:

Scope:

Server API - Prompty - Web Push Notifications for SaaS Companies

Docs Home Page URL:

Supported Response Formats:

Is This an Unofficial API?:

Is This a Hypermedia API?:

Restricted Access ( Requires Provider Approval ):

Type:

Supported Request Formats:

Architectural Style: