earth2marsh + apis   771

Some Thoughts on “Design First” API Development - Marc-André Giroux - Medium
"It certainly sounds like code first is a terrible approach when reading what’s out there these days. I’d like to add a bit of nuance to it however. Implementation first, is likely almost always a bad idea. But code can be used to define interfaces also, not only the underlying implementation. I truly believe one of the best decisions GitHub and Shopify made initially with GraphQL was to have the schema be an artifact of the code, and not use the popular approach of “schema-first”. It gives our team the confidence that their changes to the interface looks right, but also avoids them from having the maintain two things at once. What if code can be used to define the interface too? After all programming languages are quite useful (one could say maybe more than YAML ;) )"
apis  design  paradigm  specifications  schema 
4 days ago by earth2marsh
eykrehbein/strest: ⚡️ Set up tests for REST in seconds with YAML
"🚀 Flexible REST Tests



🔗 Connect multiple requests: Example Embed an authorization token you got as a response from a login request in your following requests automatically

📝 YAML Syntax: Write all of your tests in YAML files

🎉 Easy to understand: You'll understand the concept in seconds and be able to start instantly (seriously!)"
apis  testing  tests  rest  github 
4 days ago by earth2marsh
Microservice API Patterns
"Our Microservice API Patterns (MAP) capture proven solutions to design problems commonly encountered when specifying, implementing and maintaining message-based APIs.
MAP focusses on message representations – the payloads exchanged when APIs are called. These payloads vary in their structure as API endpoints and their operations have different architectural responsibilities. The chosen representation structures strongly influence the design time and runtime qualities of an API. Furthermore, the evolution of API specifications and their implementations has to be governed."
apis  microservices  patterns 
10 days ago by earth2marsh
AsyncAPI and CloudEvents | AsyncAPI Initiative
"Enter CloudEvents, a specification for describing event data in a common way. CloudEvents seeks to ease event declaration and delivery across services, platforms and beyond!

The purpose of CloudEvents is to establish a common format for event data description. And it makes a lot of sense when you realize they are part of the CNCF’s Serverless Working Group.

If you are doing serverless or FaaS (Function as a Service), then CloudEvents is your best friend because the event is the only information you will have in your function during runtime. No topics or channels, no servers, no subscribers. Just the event and some extra information you may need to make your function work.

CloudEvents is focused on the event and defines an envelope for your application’s data."
apis  async  asyncapi  events 
11 days ago by earth2marsh
JSON:API — Latest Specification (v1.0)
"JSON:API alternative to GraphQL that supports using HTTP rather than tunneling it with GraphQL, along with sparse fieldsets using the Zoom/Embed pattern"

A client MAY request that an endpoint return only specific fields in the response on a per-type basis by including a fields[TYPE] parameter.

The value of the fields parameter MUST be a comma-separated (U+002C COMMA, “,”) list that refers to the name(s) of the fields to be returned.

If a client requests a restricted set of fields for a given resource type, an endpoint MUST NOT include additional fields in resource objects of that type in its response.

GET /articles?include=author&fields[articles]=title,body&fields[people]=name HTTP/1.1
Accept: application/vnd.api+json
apis  json  filtering  fields  graphql 
16 days ago by earth2marsh
The next wave of API management - SD Times
"The next big thing after service mesh for APIs will be APIs as products or API management as code, according to Red Hat’s Codelli.

“There has been a lot of buzz around infrastructure as a service, where you can program your information technology landscape, and we are starting to embrace that in API management efforts so that users have a development pipeline that orchestrates their hardware and software resources as well as API artifacts,” said Codelli.

Codelli went on to explain that things like opening an API contract, mock services, service metadata, configuration of policies, and configuration of other API management aspects such as security, will start to be managed units that undergo the same scrutiny and testing as the code for APIs. 

“This will save overhead, ensuring predictable and lower risk deployment, streamlining deployment cycles, being able to provide better resolution. Those are all the same things we got with infrastructure as a service and we will get even more as we do API management as code,” he said. “APIs are extremely important and the benefits of instrumenting it as code are going to be extremely important.” "
apis  apim  management 
16 days ago by earth2marsh
Understanding RPC Vs REST For HTTP APIs — Smashing Magazine
"For the last few years, whenever somebody wants to start building an HTTP API, they pretty much exclusively use REST as the go-to architectural style, over alternative approaches such as XML-RPC, SOAP and JSON-RPC. REST is made out by many to be ultimately superior to the other “RPC-based” approaches, which is a bit misleading because they are just different. This article discusses these two approaches in the context of building HTTP APIs, because that is how they are most commonly used. REST and RPC can both be used via other transportation protocols, such as AMQP, but that is another topic entirely."
phil_sturgeon  rest  rpc  apis 
16 days ago by earth2marsh
GraphQL vs REST: Overview | Phil Sturgeon
This article aims to cover a few notable differences, and make the following points:

REST and GraphQL are totally different
GraphQL isn't a magic bullet, nor is it "better"
You can definitely use both at the same time
GraphQL is dope if used for the right thing

AND:
Ask yourself - at the very least - these following questions:

How different are your clients from each other?

Do you trust your clients to handle caching?

Do you want "dumb clients" that act like crawlers - knowing very little about the API, or clients that own a lot of the logic and know a lot about the API, using it simply as a data transfer?

Are you ok letting go of HTTP debugging proxies, cache proxies, all the knowledge your team have around HTTP, etc?

Are you just doing basic CRUD with simple JSON documents, or will your API need file upload/download too?
graphql  rest  phil_sturgeon  apis  comparison 
16 days ago by earth2marsh
phly, boy, phly :: Notes on GraphQL
"Using Github GraphQL api (issues around pagination, etc)"
graphql  github  apis 
16 days ago by earth2marsh
JSONata Documentation · JSONata
"JSONata is a lightweight query and transformation language for JSON data. Inspired by the 'location path' semantics of XPath 3.1, it allows sophisticated queries to be expressed in a compact and intuitive notation. A rich complement of built in operators and functions is provided for manipulating and combining extracted data, and the results of queries can be formatted into any JSON output structure using familiar JSON object and array syntax. Coupled with the facility to create user defined functions, advanced expressions can be built to tackle any JSON query and transformation task.



Get JSONata
Try it out at try.jsonata.org
Install the module from NPM
Fork the repo on GitHub
Find out more
Introduction at London Node User Group meetup
IBM developerWorks Tech Talk
IN NODEJS →
Introduction
Get JSONata
Find out more"
json  apis  transformation  rendering 
25 days ago by earth2marsh
Documenting a service using the microservice canvas
In What’s a service - part 1? I described the key aspects of a service, which includes its API, and its dependencies. A good way to document a service and its structure is to use a microservice canvas. A microservice canvas is concise description of a service. It’s similar to a CRC card that’s sometime used in object-oriented design.

I first read about the canvas back in 2017 in an DZone article by Matt McLarty and Irakli Nadareishvili. I’ve since adapted the structure of the canvas so that it emphasizes the interface (top of the canvas) and the dependencies (bottom of the canvas) and de-emphasizes implementation (middle of the canvas).
microservices  apis  design 
9 weeks ago by earth2marsh
Building the next generation of the Twitter API
"We believe developers help improve Twitter and strengthen the public conversation, and we want to help them succeed with their goals far into the future. That’s why today we’re sharing the first stage of our plan to build the next generation of the Twitter API, starting with our new Twitter Developer Labs program. We’re launching this new program so developers can test new API products early and share feedback. We know the best future version of our API will come from creating it together with the people who use it most."
twitter  apis  labs  experiment  developer 
may 2019 by earth2marsh
Client-Driven APIs - Speaker Deck
""Putting API clients in control of the API structure and data they want to consume will be the future of APIs. This is a basic concept behind GraphQL. This presentation discusses the evolution of APIs prior to GraphQL and lays the foundation for a demo ideas leveraging GraphQL as a description language to build custom HTTP APIs.
apis  history  design  tooling  tools 
may 2019 by earth2marsh
Exec Warns APIs, ISO 20022 Incompatible | PYMNTS.com
industries take note... what got you here may not get you there
apis  standards  finance  design 
may 2019 by earth2marsh
Soft and Hard Power in Software Governance
"Soft power applies to change agents within a company who may have the responsibility of achieving technology initiative outcomes, but lack the authority over all the participants. They cannot command people to comply. Instead, they have to rely on a different set of actions: diplomacy, strategic communication, assistance, negotiation, and community building. These actions share an inclusive vision for the future that others embrace without being told.

Creating standards or processes with a soft power approach may be as simple as stating a new expectation for teams to aspire to in a public forum. Or it might be a mutual agreement between parties on how to move forward on a particular issue.

Soft power excels when the situation is new and/or evolving rapidly. During this phase of an initiative, it is beneficial to adapt to new information while experience is gathered. Needs, some of which could not have been anticipated ahead of time, can be rapidly responded to. In cases where governance does not know what the final outcome should be, where flexibility and experimentation are most important, soft power should be the preferred approach until a desirable tenable solution is discovered."
governance  power  APIs  software 
may 2019 by earth2marsh
Weeding is Fundamental - 99% Invisible
"There are specific guidelines that come along with book weeding. McKellar, and many other librarians, at libraries all over the world, weed their shelves using the same set of guidelines. And it has an excellent acronym: MUSTY.  

M — for Misleading, or factually inaccurate.
U — for Ugly
S — for Superseded by a new edition or a much better book.
T — for Trivial and
Y for Your-collection-has-no-use-for-this-book. Because they want this acronym to work.
The T and the Y are the tricky ones. They’re not necessarily statements of fact; they’re judgments of value. What’s trivial to me might be very important to you, and vice versa. Even here, these judgment calls are made by librarians who specialize in the relevant section, and based on circulation statistics. You just have to trust that your librarians are doing their best for the public."
apis  weeding  books  libraries  library  techniques 
may 2019 by earth2marsh
Principles of Designing & Developing an API Product [Part 1 of 4]
good to hear the story of a designer struggling with API design
apis  design 
may 2019 by earth2marsh
Twitter opens Developers Labs program to test new API products | VentureBeat
"Twitter has chosen path versioning (specify a version as part of the endpoint URL) over header versioning (make a versioned or unversioned call). The company says path versioning is widely adopted, easy to implement for developers, and it’s what Twitter already uses in its other APIs. After launch, Twitter plans to make a major version change within its Labs program. Twitter will increment to a new Labs version after it incorporates developer feedback.

As for addressing increasing complexity, Twitter plans to formalize the behavior of its endpoints and adopt a consistent specification format. Twitter will use OpenAPI specifications to define and expose behavior for each new Labs endpoint. Because OpenAPI uses JSON Schema to specify response objects and data types, Twitter will take inspiration from there as well."
twitter  apis  openapi  developers  labs 
may 2019 by earth2marsh
REST vs GraphQL APIs, the Good, the Bad, the Ugly | Moesif Blog
"GraphQL APIs can be exciting new technology, but it is important to understand the tradeoffs before making such architectural decisions. Some APIs such as those with very few entities and relationships across entities like analytics APIs may not be suited for GraphQL. Whereas applications with many different domain objects like e-commerce where you have items, users, orders, payments, and so on may be able to leverage GraphQL much more.

In fact, GraphQL vs REST is like comparing SQL technologies vs noSQL. There are certain applications where it makes sense to model complex entities in a SQL Db. Whereas other apps that only have “messages” as in high volume chat apps or analytics APIs where the only entity is an “event” may be more suited using something like Cassandra."
apis  graphql  gql  rest  comparison 
may 2019 by earth2marsh
API Gateways and Service Meshes: Opening the Door to Application Modernisation
"An API Gateway decouples application composition and location from external consumers. An API gateway dynamically routes external requests from end-users, mobile apps, and third-parties to various internal applications, regardless of where they are deployed.

A service mesh decouples applications from internal consumers by providing location transparency. A service mesh dynamically routes internal service-to-service requests to various applications, regardless of where they are deployed."
mesh  service  gateways  apis  definitions 
may 2019 by earth2marsh
API Transformer 2018 Insights-Becoming Bigger and Stronger Than Ever
"The unique data shows that 38% of the imported files were OpenAPI files (all versions included) while 31% of the imported files were Postman files (all versions included). Around 9% of the users brought in WSDL files."

and:
"Eliminating multiple exports to the same format per user, we observed that 72% of the files were exported to OpenAPI (versions 1.2, 2.0, 3.0). 77% of this OpenAPI chunk consisted of v.2.0 files. This shows that although v.3.0 was a popular input format, much of the developers used API Transformer to export v.2.0 files instead of v.3.0."
apis  trends  conversion  2018  apimatic  transformer 
april 2019 by earth2marsh
Typeform/openapi-micro-merge: Node library used to recursively searches a directory for a regex or pattern to find OpenAPI (fka Swagger) specs; subsequently validates, bundles and merges them into one spec. Optionally writes merged spec to a file.
"Node library used to recursively search a directory for a regex or pattern to find OpenAPI specs; subsequently validates, bundles and merges them into one spec. Optionally writes merged spec to a file.

This is very useful for microservice environments where service specs are stored in separate directories, but need to be merged into one file for various purposes (docs, tooling, etc). Intended to be used in CI environments, where validating specs is a critical need.

"
apis  openapi  specs  merge  merging  tools 
march 2019 by earth2marsh
Deltacloud - Wikipedia
"Deltacloud is an application programming interface (API) developed by Red Hat and the Apache Software Foundation that abstracts differences between cloud computing implementations. It was announced on September 3, 2009.

Each Infrastructure-as-a-Service cloud existing today[when?] provides its own API. The purpose of Deltacloud is to provide one unified REST-based API that can be used to manage services on any cloud. Each particular cloud is controlled through an adapter called a "driver". As of June 2012, drivers exist for the following cloud platforms: Amazon EC2, Fujitsu Global Cloud Platform, GoGrid, OpenNebula, Rackspace, RHEV-M, RimuHosting, Terremark and VMware vCloud. Next to the 'classic' front-end, it also offers CIMI and EC2 front-ends. Deltacloud is used in applications such as Aeolus to prevent the need to implement cloud-specific logic."
apis  meta  noramlized  cloud  history 
march 2019 by earth2marsh
Transposit
YQL the next generation?


Connect
Instantly connect to APIs without the grunt work of authentication, pagination, retries, and more.

Compose
Compose
Use SQL and JavaScript to create and explore composable apps in real time, customized for your needs.

Collaborate
Collaborate
Share specified data with only the people you want.
apis  mashups 
march 2019 by earth2marsh
medmain/deepr: A specification for invoking remote methods, deeply!
"GraphQL introduced a powerful idea — the ability to invoke multiple methods in a single call, and more importantly, the ability to invoke methods based on the results of other methods. However, we feel that the design of GraphQL is not quite right. Some crucial points are missing and some features should be removed or implemented at different layers of the stack.

First of all, with GraphQL it is not possible to invoke methods on collections. When we specify a query for a collection, it is executed on the elements of the collection, but not on the collection itself. To solve this issue, it is necessary to introduce some additional models, as Relay does with the Connections. We think that such a solution adds complexity and confusion.

"
apis  design  style  omg 
march 2019 by earth2marsh
Trusted Types help prevent Cross-Site Scripting  |  Web  |  Google Developers
"We've created a new experimental API that aims to prevent DOM-Based Cross Site Scripting in modern web applications."
browser  security  javascript  xss  apis  google 
march 2019 by earth2marsh
Can you ever (safely) include credentials in a URL? – Intelligent Security
"It was soon realised that using a URL like http://www.google.com:search@example.com was a really easy way to create convincing-looking phishing links.
If the target of the URL is a login endpoint, then the attacker can attempt to get you to click on the link to perform a Login CSRF attack. In this case the honest user ends up with a session cookie for an account under the control of the attacker.
For all these reasons, this specific form of URL was deprecated back in 2005, and now support within browsers is patchy: Safari for instance will just silently ignore any username:password component when following such a link. Other browsers will tolerate them in some cases, but this varies considerably by browser and often by version to version. Some versions of Chrome refuse to follow such links and instead display a large red phishing warning page."
security  apis  resources  urls  deprecation  patterns 
march 2019 by earth2marsh
API Gateways are going through an identity crisis – solo.io – Medium
"API Gateways are going through a bit of an identity crisis these days.

Are they centralized, shared resources that facilitate the exposure and governance of APIs to external entities?
Are they cluster ingress sentries that tightly control what user traffic comes into the cluster or leaves it?
Or are they some kind of API coalescing glue to more succinctly express an API depending on the type of clients it may have?
And of course the elephant in the room and a question I often hear: “does service mesh make API gateway obsolete?”"
gateways  apis  microservices  contracts 
february 2019 by earth2marsh
We've only just begun to capitalize on enterprise APIs | ZDNet
"Developers, architects and other professionals also will realize career benefits as they build out an API-enabled culture. "You can enable people to get at data data much quicker," Mason says. "You give people more time for their jobs by normalizing access, and helping drive reuse and agility. You're responding to strategic requirements. That's great for your career. If you want a defensible job in the future, somebody who manages productized APIs.. is going to keep it for the long haul because every new technology trend leverages APIs. Every connection to IT -- even augmented reality, machine learning and AI -- is through one or more APIs.""
culture  apis  enterprise 
february 2019 by earth2marsh
Overcoming RESTlessness
"In defense of REST, it is tempting to take these criticisms at face value and come up with counterpoints like these:

For the GraphQL case, nothing in the REST paradigm prevents consumer choice or resource aggregation (it has merely been a common practice to use static interfaces on single resources) and there is plenty of information suggesting that constraining consumer choice has its own benefits
For gRPC, runtime optimization is unlikely to be the primary bottleneck in most distributed architectures, and gRPC's embedded library requirement -- not to mention protobuf's enumerated structure -- can lead to unforeseen issues
For async, there is absolutely a need to include event-based scenarios, but those are likely in addition to synchronous patterns like queries and commands
However, in my opinion these counter arguments do not tell the whole story.2 Software engineering is a restless industry, and we frequently oversimplify our problems in order to justify overly simplistic solutions. We like to label the "burning platform" so we can incent people to leap to some new safety. Real-time processing is good because batch is bad. Microservices are good because monoliths are bad. Using REST as the bogeyman on a context-by-context basis like the arguments above creates a series of false dichotomies. Rather than looking at what REST lacks in each of the above scenarios, perhaps we should examine a different question: how did REST become the default communication approach for component-to-component network hops in distributed computing? "
matt_mclarty  apis  styles  trends  graphql  grpc  openapi  rest  json  history 
february 2019 by earth2marsh
Why there is no such thing as the Richardson Maturity Model - DEV Community 👩‍💻👨‍💻
"Richardson himself at RESTFest 2015, in a talk subtitled "What Have I Done?", described the whole thing as "very embarrassing" and clarified that if you want to proceed up the steps of the Maturity Heuristic, you have to have either a technical reason or a political reason to do so. There is also no prize or "glory" at the top - sorry to disappoint. (https://vimeo.com/147237932)"
apis  mike_ralphson  rest  hateoas  maturity  richarson 
february 2019 by earth2marsh
API gateway pattern
"Forces
The granularity of APIs provided by microservices is often different than what a client needs. Microservices typically provide fine-grained APIs, which means that clients need to interact with multiple services. For example, as described above, a client needing the details for a product needs to fetch data from numerous services.

Different clients need different data. For example, the desktop browser version of a product details page desktop is typically more elaborate then the mobile version.

Network performance is different for different types of clients. For example, a mobile network is typically much slower and has much higher latency than a non-mobile network. And, of course, any WAN is much slower than a LAN. This means that a native mobile client uses a network that has very difference performance characteristics than a LAN used by a server-side web application. The server-side web application can make multiple requests to backend services without impacting the user experience where as a mobile client can only make a few.

The number of service instances and their locations (host+port) changes dynamically

Partitioning into services can change over time and should be hidden from clients

Services might use a diverse set of protocols, some of which might not be web friendly

Solution
Implement an API gateway that is the single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services."
design  apis  gateways  patterns  management 
february 2019 by earth2marsh
Creating an Effective API Program - LaunchAny - API & Microservice Consulting
Classic James
"Effective API programs require three key ingredients:

API portfolio ownership that meets the needs of both internal and external stakeholders,
Lightweight governance that combines coaching with consistency, and
Ease of API adoption for increased speed and efficiency.
Let’s examine each one to better understand what your organization may be missing or need to improve upon for your API program.

"
governance  apis  portfolios  management  programs 
february 2019 by earth2marsh
OpenAPI and gRPC Side-by-Side – APIs and Digital Transformation – Medium
"Application Programming Interfaces that operate across a network of computers. They communicate using network protocols including HTTP, and are frequently produced by different organizations than the ones that consume them.
That last phrase is a big deal: it’s the key to the value and challenge of networked APIs. Because they are frequently produced by different organizations than the ones that consume them, networked APIs make it possible for us to work together with people anywhere in the world, and they allow us to make things that are bigger than any of us could create individually… but we have to be able to talk to each other about what we’re doing. We need a language for describing APIs.

OpenAPI is a language for describing REST APIs.
If you’re working with REST APIs, you’ve probably heard of the OpenAPI Specification or its precursor, Swagger. It’s a structured way of describing REST APIs using JSON or YAML that was originally created to better document APIs. But people quickly saw other uses for it — API validation, code generation, mocking, testing — lots of great applications that make it easier to create and use APIs. "
google  grpc  openapi  tim_burks  apis  styles 
february 2019 by earth2marsh
The Three Principles of Excellent API Design | Nordic APIs |
Lovely!
"Arnauld’s Three Principles
Good design can be broken up into three main aspects, says Arnauld, and those are purpose, usability, and constraints. If you bear each principle in mind when building an API — or any household object for that matter — you’ll come away with a fantastic result."
apis  design  arnauld_lauret  principles  usability 
february 2019 by earth2marsh
Stop Calling Your APIs Microservices | Stoplight API Corner
"Strictly speaking, the term API only describes the interface, the shared language that client and server, API consumer and API provider, use to exchange information. For the API consumer, the API is nothing more than a description of the interface and an endpoint URL or set of URLs. URLs are one of the basic but somewhat magical building blocks of the web that allow a client to access information or services without knowing the nature or location of the server. Clients may remain ignorant of whether the URL leads to a Raspberry Pi hidden in someone’s basement, or a worldwide delivery network of massive data centers on every continent, as long as they receive a response. That is one of the things that make APIs so exciting because developers of all kinds can tap into infrastructure built and exposed by others to enhance their applications with additional functionality.

API providers, however, have to not only design, implement, and document the API, but also think about the infrastructure behind it. In the era of cloud computing though, that rarely means buying hardware and renting data center space anymore. Instead, API providers can choose from various as-a-service offerings, from managed clusters of virtual machines or containers, to fully serverless code hosting environments. Regardless of the infrastructure choice, at some point, the API needs to be deployed.

Do you see what I did there? I talked about deploying the API when what I meant to say was to deploy whatever code and infrastructure are required to expose the API. From a provider’s perspective, the API is not some magical door, but a tangible asset that needs to live somewhere. And, increasingly often, as companies move to a microservice architecture, that asset is … a microservice, or a set of microservices."
apis  microservices  stoplight 
february 2019 by earth2marsh
From Zero To Global: APIs at the BBC | Nordic APIs |
"Some advantages they found in this solution were:

Simple to set up and roll out – only a few DNS changes
Limited service impact
Organization-level analytics
Simple onboarding process
Unfortunately, Rafal says that given “the size of the organization, things started to deteriorate.” One such example of this is that a misconfigured proxy on the API management layer would lead to outages because of the single point of failure.

In other words, as Rafal puts it, “when it goes wrong, it goes wrong for everybody.” When you’re only dealing with one API or a single designated team, that might not be such a big problem. When you’re dealing with a large number of APIs and a large number of different teams, however, it can be a killer.

It was quickly becoming clear that, for the BBC, an off-the-shelf solution wasn’t going to cut it.

Decentralizing API Management
The answer, in Nathan’s mind, was an independently scalable solution. Plus, he says, they wanted to “give that control back to the teams that know their product best.” After evaluating their needs, the team discovered their management platform must be:

Reliant
Configurable
Extensible
Cost-effective
Ultimately that meant an entirely new architectural model, with a management solution that sits in front of each of the API services. “Nothing new to you today,” Nathan points out, “but something that was very new 2 or 3 years ago.”

The process didn’t, however, end there. We’ve already seen evidence above to confirm Nathan’s assertion that “the BBC is one BBC, but behind the scenes, it is nearly multiple organizations.”"
bbc  apis  management  apim  collaboration 
february 2019 by earth2marsh
Bizcoder - Optimizing for the Speed of Light
"It is true three women can't make a baby in 3 months, but it also doesn't take 27 months for them to have 3 babies!

You might be wondering what on earth I am talking about but this is something I see API developers getting confused about regularly. There is oft-repeated guidance that if an API needs to make multiple calls, it is more efficient to bundle them into a single call. The reasoning is based on one universal truth and one piece of legacy dogma."
darrel_miller  http  batching  caching  apis  design 
february 2019 by earth2marsh
In Record Time: How we Quickly Built a Serverless app with Firebase and Flutter (GDD Europe '17) - YouTube
Starting around 8:14, David DeRemer describes using the Firebase realtime database as the communication channel that the Hamilton app used to implement all of its services "with zero networking code."
apis  firebase  apps  network  serverless 
february 2019 by earth2marsh
API Security news, community, tools, standards, newsletter
"APISecurity.io is a community website for all things related to API security. Our daily news and weekly newsletter cover the latest breaches, vulnerabilities, standards, best practices, regulations, and technology.

"
security  apis  openapi 
february 2019 by earth2marsh
Designing API's For Enterprise Data Integration - Google Groups
"just to drive matt's very valid point home: if you directly expose a
database, you expose a very specific implementation of a data model, and
probably one that has all kinds of funky details in it that are a
side-effects of the implementation platform, how it was designed, and
how it evolved over time. trying to avoid this implementation-centric
view can be extremely valuable when it comes to the developer experience
(DX) of your API. so definitely do try to start from users, use cases,
any kind of information that is not about the implementation of the data
model, and then use this as the foundation for your API design. "
apis  databases  design 
february 2019 by earth2marsh
US9959198B1 - Simulated testing of API - Google Patents
"A definition for the API is received. A request and response model is built for each defined operation of the API resource using the received definition. A simulated response for each defined operation of the API resource is generated in an API development environment according to the request and response model."
patents  self  apis  testing 
february 2019 by earth2marsh
US10194001B1 - Automatic discovery of API information - Google Patents
"Automatic discovery of API information is disclosed, including: receiving a transaction; obtaining a determined signature from the transaction; and determining that the determined signature comprises a candidate signature to potentially add to an application programming interface (API) model."
patents  self  apis  discovery 
february 2019 by earth2marsh
REST is the new SOAP – freeCodeCamp.org
warning: clickbait title (prob why I didn't pin it when it came out?)
seems like the author is questioning HATEOAS (agree) and lamenting the deification of HTTP in API design, preferring to just tunnel in, afaict.
rest  criticism  critique  rant  APIs  design  styles 
february 2019 by earth2marsh
Gotransverse Billing API | API Reference
has "filter" example for searching
filter: string
in query
API query language string. The syntax of the API query language is similar to SQL, the criteria are expressed in the form of predicates. On the left side of the equation, there is a name of the available query parameter (for example, billing_account_id). On the right side, there is a constant value in single quotes ('sample value'). Brackets are used to group predicates, for example, '(start_date GT '1994-01-24T23:33:07+00:00')'. Use the following logical operators: AND - conjunction, OR - disjunction, NOT - negation. Compare operators: NEQ - Not equals, EQ - Equals, LT - Less, LTE - Less or equals, GT - Greater, GTE - Greater or equals, IS NULL - Is null, IS NOT NULL - Is not null, LIKE - Match pattern (LIKE operator is only applicable to parameters of the string type). Wildcard characters: '%' - matches any number of characters, including no characters, '_' - matches exactly one character. Here is the sample query: the account_num GT '15' AND (name LIKE 'start of name% end of name' OR status EQ 'ACTIVE').
apis  spectacle  filtering  documentation  example 
february 2019 by earth2marsh
An Insider’s Take on API Strategy | Okta
"First, the good news:

98% of respondents said they had an API strategy in place
95% are planning to invest in APIs in the near future
28% said their strategies were already “successfully planned and implemented”
An additional 44% said their strategies were “likely to succeed”
But there’s some bad news too:

Only 36% said Security teams perform audits of their APIs
Only 4% said Product Managers approve the launching of their APIs
Only 8% of respondents said Engineering, IT, Security, and Product Management were all involved in API security
"
survey  apis  security  okta 
january 2019 by earth2marsh
twitter/diffy: Find potential bugs in your services with Diffy
"Diffy finds potential bugs in your service using running instances of your new code and your old code side by side. Diffy behaves as a proxy and multicasts whatever requests it receives to each of the running instances. It then compares the responses, and reports any regressions that may surface from those comparisons. The premise for Diffy is that if two implementations of the service return “similar” responses for a sufficiently large and diverse set of requests, then the two implementations can be treated as equivalent and the newer implementation is regression-free."
apis  services  testing  twitter  tools 
december 2018 by earth2marsh
Service-oriented architecture - Wikipedia
These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.[8]

A manifesto was published for service-oriented architecture in October, 2009. This came up with six core values which are listed as follows:[9]

Business value is given more importance than technical strategy.
Strategic goals are given more importance than project-specific benefits.
Intrinsic inter-operability is given more importance than custom integration.
Shared services are given more importance than specific-purpose implementations.
Flexibility is given more importance than optimization.
Evolutionary refinement is given more importance than pursuit of initial perfection.
SOA can be seen as part of the continuum which ranges from the older concept of distributed computing[7][10] and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA).[11]

Principles
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of these[12][13][14][15] include the following:

Standardized service contract
Services adhere to a standard communications agreements, as defined collectively by one or more service-description documents within a given set of services.
Service reference autonomy (an aspect of loose coupling)
The relationship between services is minimized to the level that they are only aware of their existence.
Service location transparency (an aspect of loose coupling)
Services can be called from anywhere within the network that it is located no matter where it is present.
Service longevity
Services should be designed to be long lived. Where possible services should avoid forcing consumers to change if they do not require new features, if you call a service today you should be able to call the same service tomorrow.
Service abstraction
The services act as black boxes, that is their inner logic is hidden from the consumers.
Service autonomy
Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.
Service statelessness
Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
Service granularity
A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.
Service normalization
Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done, These are the cases where performance optimization, access, and aggregation are required.[16]
Service composability
Services can be used to compose other services.
Service discovery
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
Service reusability
Logic is divided into various services, to promote reuse of code.
Service encapsulation
Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.
soa  patterns  apis  principles 
december 2018 by earth2marsh
The Zoom/Embed Pattern - The RESTed NARWHL
"The Zoom/Embed pattern provides for finer grained control over the data returned by allowing the developer to specify that one or more resources related to the requested resource be returned embedded within the response. While this can add significantly to the response payload a client receives, it gives the client developer an opportunity to decide whether that additional payload provides better performance over making additional calls."
APIs  design 
december 2018 by earth2marsh
Pros and Cons of GraphQL – The Hotels.com Technology Blog – Medium
"If we remove the rose-colored glasses and disable the reality distortion field, then some tradeoffs become apparent.

kiss HTTP caching goodbye, everything is POST
GraphQL has some aspects of earlier Facebook tech that did not go so well, see FQL
Will GraphQL servers become big and bloated? Without engineering discipline, it feels likely
Are we becoming too dependent on the Apollo client? Alternatives exist, including plain old POST, but Apollo has momentum and developer mindshare"
apis  graphql  design 
november 2018 by earth2marsh
[no title]
maybe ~300 respondents? Not great insights here, but something.
apis  developers  survey 
november 2018 by earth2marsh
Erik Wilde on Twitter: "for context: my claim here at @OReillySACon was that the winning #API marketplace will not be decided by search capabilities. instead, it will depend on its utility to provide meaningful and rich API context that devs and API manag
"for context: my claim here at @OReillySACon was that the winning #API marketplace will not be decided by search capabilities. instead, it will depend on its utility to provide meaningful and rich API context that devs and API managers need to decide which APIs to choose."
apis  marketplaces 
november 2018 by earth2marsh
A Gardener's Approach to Growing an API Culture
a lovely talk from Matt

"The fast parts learn. The slow parts remember. The fast parts propose things, the slow parts dispose things. The fast and small instruct the slow and big with accrued innovations and occasional revolutions. At the same time, and we don't respect this as much as we should, the big and the slow control the fast and the small with constraints and with constancy. All the attention is paid to the fast parts. But all the power is in the slow parts. - Steward Brand"
apis  design  culture  change  transformation  infrastructure  pace  governance 
november 2018 by earth2marsh
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:

while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
['remindOnRespondedEventsOnly','true'],
['hideInvitations_remindOnRespondedEventsOnly','false_true'],
['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 
november 2018 by earth2marsh
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:

Facebook

Gmail

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 
november 2018 by earth2marsh
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  governance 
november 2018 by earth2marsh
« earlier      
per page:    204080120160

related tags

abstraction  abstractions  abuse  accept  access  accounts  adaptive  addon  addons  addressing  adoption  adventure  advertising  advice  agility  airways  ajax  alternative  alternatives  amazon  analytics  android  annotations  antipatterns  api  apiary  apicraft  apidesign  apievangelist  apigee  apikeys  apim  apimatic  apis  apistrat  apistudio  apithedocs  apitrends  app  appengine  apple  application  applications  approach  approachs  approvals  apps  architecture  argument  arnauld_lauret  arrays  art  assessment  async  asyncapi  atom  attack  authentication  authoring  authorization  availability  awesome  baas  backbone  backend  badges  badging  banking  banks  barcelona  based  basic  batch  batching  bb8  bbc  benetits  bestpractices  best_practices  bigdata  billboard  binary  blech  blog  blogs  blueprint  blunders  body  bookmarklet  books  boston  boundaries  box  brand  branding  brands  Brazil  breaking  british  broker  browser  browsers  bugs  build  builder  business  buy  cache  caching  calculate  calculator  capitalone  casing  cert  certificate  change  changes  chart  cheatsheet  checklist  choices  chrome  CI  cicd  Cisco  cities  city  class  classification  cli  client  clients  clone  cloud  cms  code  codes  coding  collaboration  commentary  comments  commercial  communication  community  compare  comparison  compatibility  competition  complexity  compliance  components  composition  conference  connectors  consider  console  consoles  constraints  consumer  consumption  content  context  continuous  contracts  control  controls  conversion  convert  converter  cookies  copy  copying  copyright  cors  cost  count  countries  counts  coupling  courts  craft  crawling  creating  creation  criticism  criticisms  critique  crowds  crud  culture  curl  currency  custom  dark  darrel_miller  data  database  databases  datamodel  dave_winer  debugging  decisions  deck  definition  definitions  delete  delicious  delimiters  demo  dependencies  deprecation  describing  description  descriptions  design  developer  developerexperience  developers  development  devices  devrel  devx  diagram  diagrams  dice  discovery  distance  distributed  docker  docs  documentation  dogma  domain  driven  droid  dropbox  drupal  dsl  dx  Ebay  ebook  eclipse  ecosystem  editor  editors  ehr  email  embed  embeds  encoding  encryption  endpoints  enforcement  engagement  engineering  enterprise  entities  episod  errors  espionage  etags  ethics  eu  eucalyptus  europe  evangelism  evented  eventedweb  evented_web  events  evernote  evolution  example  examples  experience  experiment  exploits  Explore  explorer  export  extension  extensions  external  facade  facebook  facts  features  federation  Feedly  fetch  fieldguide  fielding  fields  file  files  filtering  finance  financial  finserv  fintech  firebase  first  flickr  flow  flowchart  flows  format  formats  foursquare  fragility  framework  free  frontend  functions  funny  future  game  gamification  gateway  gateways  gem  generated  generation  generator  geo  GET  gilt  github  glitch  gluecon  golang  google  google:accounts  google:appsscript  Google:charts  google:sheets  goverment  governance  government  gql  graph  graphic  graphics  graphql  greg_brail  grpc  guest  guide  guidelines  guides  hapi  hardening  hateoas  head  headers  health  heroku  hierarchy  history  hmac  hosting  howto  html  html5  http  https  humans  humor  hypermedia  hypertext  ibooks  ide  idempotency  Idempotent  identifiers  identity  ids  ietf  iframe  iframes  ifttt  iftttFeedly  iftttGR  implementation  infographic  infographics  infrastructure  innovation  inspiration  instapaper  integration  intent  Intents  Interactive  interesting  interfaces  internal  internet  interviews  intro  ios  iot  ipad  iphone  ISS  issues  java  javascript  jdbc  jersey  johnsheehan  john_musser  john_sheehan  jonathan_beri  journalism  journalists  journey  joyent  jquery  json  jsonapi  JSONP  jwt  keen  kevin_swiber  keychain  keys  kindle  kin_lane  kpis  labels  labs  language  latency  launch  launcher  law  laws  lawsuit  layer  layers  Lean  learning  legal  lib  libraries  library  license  licensing  lifecycle  lightweight  limiting  limits  linkedin  linking  links  list  lists  live  load  location  logging  logic  logs  machine  machines  management  mapping  maps  markdown  market  marketing  marketplaces  mashup  mashups  materialdesign  matrix  matt_mclarty  maturity  me  measurement  mediatypes  medium  merge  merging  mesh  messages  messaging  meta  metadata  metamodel  methods  metrics  micro  microblogging  microservices  microsoft  mike_ralphson  mime  mimetypes  mission  mistakes  mma  mnot  mobile  mocking  mocks  model  modeling  models  moderation  module  monetization  monitor  monitoring  monitors  mozilla  msa  multiple  Muni  museums  musser  mvc  mysql  names  naming  nasa  native  needs  netflix  network  newrelic  news  node  nodejs  noramlized  notification  notifications  nps  numbers  oauth  oauth2  object  objectivec  objects  obscurity  offline  okta  omg  omgwtf  online  opacity  opaque  open  openapi  opensource  openstack  opinion  options  oracle  overlays  ownership  paas  pace  pagination  pain  panel  paper  papers  paradigm  parameters  parking  parser  partial  partners  passwords  patch  patents  pattern  patterns  payment  paypal  pdf  pending  people  performance  periodic  personality  personas  philosophy  phil_sturgeon  phonegap  php  pinboard  ping  pinning  pitfalls  planning  platform  platforms  playground  plugin  plus  policies  policy  political  politics  polling  portal  portals  portfolios  poses  post  postel  Posterous  postman  power  pragmatic  prediction  predictive  premium  presence  presentation  presentations  pricing  principles  printing  privacy  private  problems  process  processing  production  productmanagement  products  program  programmableweb  programming  programs  projects  proposal  proprosals  protobuf  protobufs  protocol  protocolbuffers  protocols  protos  providers  proxy  publishing  pubsub  push  PUT  Put  python  ql.io  qraphql  quality  queries  query  quirks  quiz  quotas  quote  rails  raml  range  rant  rate  ratelimiting  ratelimits  ratings  rationale  react  realtime  records  reddit  redmonk  reference  religion  rendering  report  representation  requests  research  resource  resources  response  responsecodes  rest  restful  restrictions  review  rewards  rfc  richardson  richarson  roi  roles  roy_fielding  rpc  ruby  runscope  saas  samples  sandbox  schema  schemas  scopes  scorecard  scraping  script  sdk  sdks  search  secrets  secure  security  self  semantic  semantics  sentiment  sequencing  serverless  servers  service  services  sharecropping  shopify  signup  simplicity  singapore  sins  skd  skidded  skydrive  sla  slack  slas  slides  slow  smart  smartbear  snippets  soa  soap  social  software  Sonos  soundcloud  source  spa  space  spam  spec  specification  specifications  specs  spectacle  spreadsheet  spreadsheets  sql  sse  ssl  sso  stackexchange  stackoverflow  standard  standards  startup  startups  starwars  static  status  stephen_klabnik  steve_willmott  stoplight  storage  strategies  strategy  streaming  string  stripe  structure  studio  style  styleguide  styles  subbu  subscribe  subscriptions  Substantial  sun  sunset  support  surveillance  survey  swagger  swagger-node  sxsw  sync  synology  table  tactics  talk  tasks  tax  taylor  tdd  techniques  technology  telecom  template  templates  tension  terms  testing  tests  text  thinkup  thread  threads  threes  thrift  ticketmaster  tiers  timeline  tim_burks  tips  tokens  tolls  tony  tony_tam  tool  tooling  toolkit  tools  topics  tos  toxicity  to_read  tradeoff  tradeoffs  transformation  transformer  Transit  transport  trello  trends  trial  trust  tumblr  tutorial  tutorials  tweets  twilio  twitter  twofactor  type  uber  ui  undocumented  Update  upload  uri  uris  url  urls  USA  usability  usage  Useragent  users  ux  variables  vector  verbs  versioning  versions  via:kinlane  via:pineappleagogo  via:pocket  video  videos  vine  virtualization  visual  visualization  volos  vulnerability  w3  wadl  walgreens  warnings  wars  web  webapis  webdav  webdev  webhooks  webinar  Webintents  webservices  websockets  weeding  wget  whitepaper  widgets  wife  Windows  wolfram  wordpress  workflow  writing  wsdl  xkcd  xml  xss  yagni  yaml  yelp  yo  yoga  youtube  zapier 

Copy this bookmark:



description:


tags: