javascript - Why does Google prepend while(1); to their JSON responses? - Stack Overflow
"Why does Google prepend while(1); to their (private) JSON responses?

For example, here's a response while turning a calendar on and off in Google Calendar:

['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]
I would assume this is to prevent people from doing an eval() on it, but all you'd really have to do is replace the while and then you'd be set. I would assume the eval prevention is to make sure people write safe JSON parsing code.

I've seen this used in a couple of other places, too, but a lot more so with Google (Mail, Calendar, Contacts, etc.) Strangely enough, Google Docs starts with &&&START&&& instead, and Google Contacts seems to start with while(1); &&&START&&&."
javascript  json  security  apis 
1 hour ago
Why Facebook's api starts with a for loop - DEV Community 👩‍💻👨‍💻
"If you ever inspected your requests to big company's API's in the browser, you might have noticed some weird javascript before the JSON itself:



Why would they waste few bytes to invalidate this JSON?

To protect your data
Without those important bytes, it could be possible for any website to access this data.

This vulnerability is called JSON hijacking, and allows websites to extract the JSON data from those API's."
json  javascript  security  webdev  vulnerability  apis  facebook 
1 hour ago
How to create an API style guide, and why - Tyk API Gateway and API Management - How to create an API style guide, and why
James, again "Many API programs begin as a single API. Over time, more APIs emerge across the company. Consistency for your API consumers – whether they are internal, partners, or public developers – is an important component of a great developer experience. A common design approach makes integration more intuitive and can reduce troubleshooting and support cost.

However, style guides often bring with it the need for centralised governance and migration paths for existing APIs that do not meet guide recommendations. How do you balance all of these concerns, without strict enforcement and negative consequences for API consumers?

In this article, I’ll share some details about what makes a great API style guide, how to avoid the one-size-fits-all mistake, and some techniques some of my clients are using to drive toward consistency without requiring unnecessary governance processes.

apis  design  style  styleguide  guides 
3 days ago
Footpath Route Planner
want, for Android
"Plan routes
in seconds flat
Trace a map and bring your
next adventure to life."
app  iphone  Ios 
4 days ago
GitHub Universe 2018: Low Key Revolutionary – James Governor's Monkchips
"Actions allows a developer to write event-driven workflows in whatever programming language they want, which run on containers hosted by GitHub.

Being able to run scripts on the platform sounded almost trivial at first listen. But the deeper implications of GitHub as a runtime will become clearer over time.

Firstly GitHub is embracing and extending CI/CD. While the firm was keen to avoid the language of CD or pipelines in its use cases out of respect for partners, it was clear GitHub Actions is worrying for partners – most notably CircleCI and TravisCI. Running tests and builds on GitHub itself, is becoming a reality. I won’t go into implications for competitors such as Atlassian, Cloudbees and GitLab here – that’s a subject for another post, where we also look at porfolio rationalisation opportunities and challenges for GitHub Enterprise and the new Azure DevOps suite.

In the longer term the disruption Actions will enable will go much further than hosted CI however. As our industry has repeatedly demonstrated, platforms that begin by encroaching on dev/test become full blown production environments in their own right over time. We had the VMware pattern, then the AWS pattern, then the Docker pattern, and now the GitHub pattern emerges. Start with dev/test and QA and eventually workloads migrate to the platform. The notion GitHub will become an infrastructure platform involves a degree of extrapolation.

github  actions  serverless 
6 days ago
Features • GitHub Actions
"Powerful workflows to supercharge your repos
Workflows can be triggered by GitHub platform events (i.e. push, issue, release) and can run a sequence of serial or parallel actions in response. Combine and configure actions for the services you know and love built and maintained by the community.

Want to venture off of the beaten path? Actions can be written in any language using the millions of Open Source libraries available on GitHub and can interact with the full GitHub API and any other public API."
github  actions  automation  serverless 
6 days ago
The Linux Foundation Announces Intent to Form New Foundation to Support GraphQL - The Linux Foundation
"Unlike REST-based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need"
graphql  governance  linuxfoundation  lf 
7 days ago
RT : Thank you to the community and our fantastic roster of supporting members for 3 years in !…
opensource  from twitter
8 days ago
5 things you need to fix in your API documentation - Osaango - Open the right doors using APIs!
maybe only 3 things? but decent "1. What does your API do?

This should be obvious from the first title and sentence on your API documentation. And for each endpoint. Make sure it’s written for your target audience. The worst I’ve seen is “Search API: Search API is used to do searches”. Ok, but to search what? Why? Are there limitations or special combinations? If it’s an API in a developer portal containing public, partner and private APIs then who is this API for? Or could it you open it for everyone? This is something you would need to think about already when designing the API.

Wrong purpose, terrible API - Arnaud Lauret, API Handyman, NordicAPIs Platform Summit 2018

This is also the starting point in the creative-commons licensed APIOps CyclesTM -method for API development. It all starts from the API Value Proposition.

2. Stop with the sequence diagrams, explain your product"
developer  experience  apis  portals 
14 days ago
Do we need API management? - Osaango - Open the right doors using APIs!

"This question is a constant topic in water coolers of every IT department and to save everyone some headache we fashioned this survey to help you.

Every time you answer "Yes" give your self a point.

Answer questions and score your answers"
apis  management  apim  quiz 
14 days ago
Kids’ Video Game Obsession Isn’t Really About Video Games | Psychology Today
What Kids Are Looking For (And Not Getting)
Fortnite, like any well-designed video game, satisfies what we are all looking for. According to Drs. Edward Deci and Richard Ryan, people need three things to flourish. We look for competence — the need for mastery, progression, achievement, and growth. We need autonomy — the need for volition and freedom of control over our choice. And finally, we strive for relatedness — the need to feel like we matter to others and that others matter to us. Unfortunately, when considering the state of modern childhood, many kids aren’t getting enough of these three essential elements.
videogames  parenting  kids 
24 days ago
GraphQL at Twitter
First, they measure query complexity. They assign a "score" (some point value) to each field, and calculate the total cost of a query. The total cost is the complexity of a query, and is calculated before execution. They then limit queries to some maximum complexity, and reject queries that are too costly.

Twitter also uses query depth measurement, which simply calculates the height of a query. For example, they could reject queries that goes further than 10 fields deep.

They don't allow arbitrary queries. All queries must be uploaded and stored ahead of time and exchanged for a unique key:

POST /graphql/eyBuaWNlIHsgdHJ5IH0gfQ
These are called stored operations or persisted queries. This protects against attackers exploring the GraphQL API or running introspection queries against it to find out what data is available or looking for vulnerabilities.
graphql  Twitter  APIs 
24 days ago
api - Hyphen, underscore, or camelCase as word delimiter in URIs? - Stack Overflow
"You should use hyphens in a crawlable web application URL. Why? Because the hyphen separates words (so that a search engine can index the individual words), and is not a word character. Underscore is a word character, meaning it should be considered part of a word.

Double-click this in Chrome: camelCase
Double-click this in Chrome: under_score
Double-click this in Chrome: hyphen-ated

See how Chrome (I hear Google makes a search engine too) only thinks one of those is two words?

camelCase and underscore also require the user to use the shift key, whereas hyphenated does not.

So if you should use hyphens in a crawlable web application, why would you bother doing something different in an intranet application? One less thing to remember."
casing  delimiters  apis  design  Style 
25 days ago
Staying on Top of Changes in GraphQL | GitHub Developer Guide
"Staying on Top of Changes in GraphQL
May 3, 2018 xuorig
To provide a more seamless experience we prefer to continuously evolve our schemas rather than using API versioning. Continuous evolution allows us to iterate faster and provide our integrators with new schema members more often. We do our best to avoid breaking changes, but sometimes it's necessary to offer an unversioned API.

We strive to provide the most stable APIs to our integrators and to provide transparency about new developments. This is why we recently shipped the brand new Breaking Changes page, which announces future breaking changes to our GraphQL schema.

Internally, our engineers mark certain schema members as deprecated using a Ruby API on top of the graphql-ruby gem. Using the changes metadata provided by our engineers, we automatically compute removal dates and generate this breaking changes page, meaning you'll always get up to date information."
github  graphql  versioning  schemas  apis  omgwtf 
27 days ago
Breaking Changes | GitHub Developer Guide
"Breaking changes are any changes that might require action from our integrators. We divide these changes into two categories:

Breaking: Changes that will break existing queries to the GraphQL API. For example, removing a field would be a breaking change.
Dangerous: Changes that won't break existing queries but could affect the runtime behavior of clients. Adding an enum value is an example of a dangerous change.
We strive to provide stable APIs for our integrators. When a new feature is still evolving, we release it behind a schema preview.

We'll announce upcoming breaking changes at least three months before making changes to the GraphQL schema, to give integrators time to make the necessary adjustments. Changes go into effect on the first day of a quarter (January 1st, April 1st, July 1st, or October 1st). For example, if we announce a change on January 15th, it will be made on July 1st."
github  changes  apis  breaking  versioning  graphql  omgwtf 
27 days ago
GraphQL Best Practices | GraphQL
While there's nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.

Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.

In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has lead to a common practice of always avoiding breaking changes and serving a versionless API."
versioning  apis  graphql  schemas 
27 days ago
Getting Specific About APIs - Phil Sturgeon
API City 2018"
Nice overview from Phil about WeWork's process
apis  presentation  workflow  openapi  schemas  tools 
28 days ago
Frisby.js Overview · Frisby
"Frisby makes REST API testing easy, fast, and fun. Frisby.js comes loaded with many built-in tools for the most common things you need to test for to ensure your REST API is working as it should, and returning the correct properties, values, and types.
When you need something custom, Frisby.js also provides an easy way to customize and extend assertions to make your job easier, with less repetitive and tedious code.
apis  testing 
28 days ago
Sandbox - Quickly create REST API and SOAP mock web services
"Accelerate application development
Quick and easy mock RESTful API and SOAP webservices. Generate from API definitions,
instant deploy, collaborative build, and debugging tools for integration.
apis  design  mocking  testing 
28 days ago Beta
"RestPoint is a powerful prototyping technology to build and deploy REST API's with backend DB's, in the cloud, using a web browser, in minutes.

Use RestPoint to experiment and test drive API's, plug in real data, share API's with others to get feedback, all before final sign off to production."
mocking  apis  design  tools  SaaS  service  visual 
28 days ago
Rapido API designer
"Rapido is an API Academy tool that lets your rapidly sketch an API design."
apis  design  tools  visual  editor 
28 days ago
Node-based API mocking that can run in proxies
apis  mocking  tools 
28 days ago
stoplightio/prism: Turn any OAS (Swagger 2) file into an API server with mocking, transformations, validations, and more.
"The perfect OAS (Swagger 2) companion. Turn any OAS file into an API server with dynamic mocking, transformations, validations, and more."
apis  openapi  mocking  tools 
28 days ago
danielgtaylor/apisprout: Lightweight, blazing fast, cross-platform OpenAPI 3 mock server with validation
"A simple, quick, cross-platform API mock server that returns examples specified in an API description document. Features include:

OpenAPI 3.x support
Load from a URL or local file
Accept header content negotiation
Example: Accept: application/*
Prefer header to select response to test specific cases
Example: Prefer: status=409
Server name validation (enabled with --validate-server)
Request parameter & body validation (enabled with --validate-request)
Configuration via:
Files (/etc/apisprout/config.json|yaml)
Environment (prefixed with SPROUT_, e.g. SPROUT_VALIDATE_SERVER)
Commandline flags"
apis  mocking  tools  openapi 
28 days ago
Getting Specific About APIs
Client-side validation
Server-side validation
Client-library Generation (SDKs)
UI Generation
Server/Application generation
Mock servers
Contract testing"
From Phil Sturgeon
apis  design  contracts  openapi  docs  benetits  cicd  presentation 
28 days ago
Mike Amundsen tweetstorm
recaps the gist from the important chapters of Fielding's Thesis, mentions where GraphQl fits (and doesn't), and contrasts REST in the wider landscape of message exchange patterns. Fielding, himself, even pops in to clarify a point
apis  design  rest  graphql 
28 days ago
REST vs. RPC: what problems are you trying to solve with your APIs? | Google Cloud Blog
"If you ask most software developers why they define and build APIs, they are likely to explain that they have an application that is implemented as multiple distributed components, and those components call each other's APIs for the complete application to function. They may also say that they are implementing the API of a service that is used by multiple applications.

When developers design APIs to solve these kinds of problems, the solution characteristics they will typically prioritize are ease of programming for both the client and the server, and efficiency of execution. RPC is a good match for these priorities. RPC fits very well with the thought processes and skills of programmers on both the producer and consumer side of an API. Calling a remote procedure is usually syntactically the same as calling a normal programming language procedure, and learning the procedures of a remote API is very similar to learning a new programming library. RPC implementations also tend to be efficient—the data that is passed between the client and the server is usually encoded in binary formats, and the RPC style encourages relatively small messages (although some care has to be taken to avoid overly chatty interactions).

If RPC is such a good fit with the rest of software development, why is there another popular model for APIs—REST—and why is there so much controversy about which to use?"
apis  design  rest  http  rpc 
29 days ago
Protobuffers Are Wrong | Hacker News
Good commentary on a possibly-insightful-but-hateful post. Touches on JSON and GraphQL. Worth a read.
apis  protobufs  rest  json  design  dogma 
4 weeks ago
An apikey is like a social security number—simultaneously both an ID and a secret. While it may be convenient, it i…
from twitter
5 weeks ago - Open Source Economy
"Utopian is the only platform rewarding contributions to Open Source projects by utilizing a decentralised, vote-based reward system built on top of the STEEM Blockchain."
blockchain  opensource  community 
5 weeks ago
google/extra-keyboards-for-chrome-os: Extra keyboard layouts and input methods for Chrome OS
"A collection of extra keyboard layouts and input methods for Chrome OS. Each directory is its own Chrome extension."
chromeos  chrome  keyboard  keyboards  dvorak  compose  characters  typing  extension 
5 weeks ago
Layering Microservices
Interesting how APIs become rocks to experience clay

"In product development, the closer to the customer a piece of software is, the more often it changes. The services on the top of the stack are where product managers and marketers want to improve the experience, where designs need to be refreshed every few months, and where most of the experimentation happens. They naturally experience more churn than other services, and this gives us an opportunity to optimize components at this layer for fast-paced change.

Components at the bottom of this diagram, on the other hand, don’t change that often. Of course, at some point someone added an attribute to a group or to a user that wasn’t there before, but this was often a big deal, surrounded by careful change management and a migration strategy from the previous to the new state.

This dichotomy is big enough to justify its own layering model. I like to call this Clay-to-Rocks:

In this model, we group services based on how frequently we expect them to change. Clay is a nickname for software that is expected to change often, usually driven by the constant changes that a modern software product requires to stay relevant. Software at this layer isn’t meant to be brittle or unreliable, but the people building it will often prioritize iteration speed over performance or resiliency.

Rocks are how we call the underlying software that enables many different use cases, the software that is so close to the core business that it will probably only change if the business model changes. Many other services depend on services from this layer, which means that they should be built and maintained with resiliency and performance in mind.

Services are usually born as clay, as the team is experimenting with new products and features. If the experiment finds product/market fit, they are usually moved down as more and more newer products and features start building on them.

microservices  layers  APIs 
6 weeks ago
Dublin Microservice "Introduction to Service Meshes"
"While service meshes may be the next "big thing" in microservices, the concept isn't new. Classical SOA attempted to implement similar technology for abstracting and managing all aspects of service-to-service communication, and this was often realized as the much-maligned Enterprise Service Bus (ESB). Several years ago similar technology emerged from the microservice innovators, including Airbnb (SmartStack for service discovery), Netflix (Prana integration sidecars), and Twitter (Finagle for extensible RPC), and these technologies have now converged into the service meshes we are currently seeing being deployed.

In this talk, Daniel Bryant will share with you what service meshes are, why they are (and sometimes are not) well-suited for microservice deployments, and how best to use a service mesh when you're deploying microservices. This presentation begins with a brief history of the development of service meshes, and the motivations of the unicorn organisations that developed them. From there, you'll learn about some of the currently available implementations that are targeting microservice deployments, such as Istio/Envoy, Linkerd, and NGINX Plus."
microservices  presentation  meshes  istio 
6 weeks ago
Credit Offers Playground | Capital One DevExchange
demo creds, curl requests (with stub for SDKs), and sequence of getting token and then calling API
apis  tools  playground  capitalone  dx 
7 weeks ago
Best Practices for API Error Handling | Nordic APIs |
Excellent recap of what large API providers do with error responses for their APIs.
research  http  errors  apis  design 
7 weeks ago
Handling Errors - Graph API
They don't use HTTP error codes. GQL side effect?
"message: A human-readable description of the error.
code: An error code. Common values are listed below, along with common recovery tactics.
error_subcode: Additional information about the error. Common values are listed below.
error_user_msg: The message to display to the user. The language of the message is based on the locale of the API request.
error_user_title: The title of the dialog, if shown. The language of the message is based on the locale of the API request.
fbtrace_id: Internal support identifier. When reporting a bug related to a Graph API call, include the fbtrace_id to help us find log data for debugging."
facebook  apis  errors  design 
7 weeks ago
Jane Street Tech Blog - Putting the I back in IDE: Towards a Github Explorer
"Imagine a system for editing and reviewing code where:

Every branch of every repo gets its own sandboxed directory. Your revision history in each branch, including uncommitted stuff, is persisted, as are build artifacts. When you switch contexts, each project is just as you left it.

Within your editor, you can pull up a global view of all your branches, your outstanding pull requests, and the pull requests you’re assigned to review. It’s one keystroke to view the summary for a pull, and one more to start editing any of its files right there under your cursor.

Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on."
ide  tools  development  git 
7 weeks ago
RT : Wanted to share sneak-peak 'pic' of the fun we'll be having next week at . Register today and join the cho…
apistrat  from twitter
7 weeks ago
config/ at master · lightbend/config
"HOCON (Human-Optimized Config Object Notation)
This is an informal spec, but hopefully it's clear.

Goals / Background
The primary goal is: keep the semantics (tree structure; set of types; encoding/escaping) from JSON, but make it more convenient as a human-editable config file format.

The following features are desirable, to support human usage:

less noisy / less pedantic syntax
ability to refer to another part of the configuration (set a value to another value)
import/include another configuration file into the current file
a mapping to a flat properties list such as Java's system properties
ability to get values from environment variables
ability to write comments
Implementation-wise, the format should have these properties:

a JSON superset, that is, all valid JSON should be valid and should result in the same in-memory data that a JSON parser would have produced.
be deterministic; the format is flexible, but it is not heuristic. It should be clear what's invalid and invalid files should generate errors.
require minimal look-ahead; should be able to tokenize the file by looking at only the next three characters. (right now, the only reason to look at three is to find "//" comments; otherwise you can parse looking at two.)
HOCON is significantly harder to specify and to parse than JSON. Think of it as moving the work from the person maintaining the config file to the computer program."
config  json  syntax  configuration 
7 weeks ago
« earlier      
!to_read addon advertising advice ajax amazon analytics android api apis apps architecture art article audio authentication backup blog book bookmarklet books browser business change chrome code cognition collaboration communication community comparison cool copyright creativity css culture data design development diy documentation economics editor education elearning email environment examples extension extensions facebook family favorite feedly finance firefox flash flickr food for free freeware fun funny future games generator github google graphics green hack hacks hardware health history home howto html http humor identity ifttt iftttfeedly iftttgr images information innovation inspiration interesting interface internet javascript jquery json kids language later law learning library life linux list lists lsi mac management map mapping maps marketing math media metrics microsoft mobile money mp3 music network online opensource organization osx parenting patterns pdf performance philosophy phone photo photography photos php plugin politics presentation privacy productivity productmanagement programming psychology read recipes reference research resource resources rest rss ruby sanfrancisco saved science script search security service sharing shopping social software startup startups statistics storage strategy sustainability teaching technique technology testing text time tips tool tools tracking travel trends tutorial twitter ubuntu ui usa usability useful utilities utility ux via:pocket video visualization web webdesign webdev wiki windows word wordpress writing xp youtube

Copy this bookmark: