Encore now supports the two most highly requested features from our users!
Encore v0.17 also comes with improvements to authentication, and lots of minor improvements and bug fixes!
Oddly enough, all of the POST endpoints for launches are under lock and key. 🔒
Many of the API design opinions found on the web are academic discussions revolving around subjective interpretations of fuzzy standards as opposed to what makes sense in the real world. My goal with this post is to describe best practices for a pragmatic API designed for today’s web applications. I make no attempt to satisfy a standard if it doesn’t feel right. To help guide the decision making process, I’ve written down some requirements that the API must strive for…
Sooo much good advice in this article. Take this golden nugget, for example:
An API is a developer’s UI - just like any UI, it’s important to ensure the user’s experience is thought out carefully!
Yes! This reminds me of the conversation Mat Ryer and I had on Backstage a few weeks back about designing a Changelog API and how I might go about doing that.
Go Time panelist Mat Ryer joins Jerod to talk through the pros and cons of GraphQL vs REST for a future Changelog API. There’s also a fair bit of language chat around Go and JavaScript, a section on Machine Learning, and some inside baseball on where Go Time is heading.
Around the advent of GraphQL, I found myself asking its proponents if HTTP/2 solves any of the same performance problems. Most of the answers were along the lines of, “it might, but that hasn’t been realized yet.” Well, Vulcain is here to realize it.
Over the years, several formats have been created to fix performance bottlenecks impacting web APIs: over fetching, under fetching, the n+1 problem…
Current solutions for these problems (GraphQL, JSON:API’s embedded resources and sparse fieldsets, …) are smart network hacks for HTTP/1. But these hacks come with (too) many drawbacks when it comes to HTTP cache, logs and even security.
Fortunately, thanks to the new features introduced in HTTP/2, it’s now possible to create true REST APIs fixing these problems with ease and class! Here comes Vulcain!
See also their comparison between Vulcain, GraphQL, and API formats.
Abhinav Asthana (founder of Postman) joined the show to talk about Postman, an ADE — API Development Environment — that began as open source and is now a full-fledged company that just announced a $50 million dollar Series B. We talk about why Postman has grown so successfully, APIs and their impact to core business factors, what it means to be an API Development Environment (ADE), and how they created one of the most popular API platforms and community.
LGTM, but why?
Mostly because I wanted to dig deeper into node web server code, but also because I haven’t jumped onto the NoSQL bandwagon and think that web APIs are extremely useful. The result is a modest attempt at automating the CRUD boilerplate that every developer hates, while following the specs to make API consumption intuitive. I chose sqlite to keep the database side of things simple, with the intent that the API isn’t serving heavy loads.
This is the perfect tool for any prototype project or proof-of-concept application needing to integrate quickly with RESTful APIs, but it’s also ideally suited as a convenience tool in larger projects that too rely on RESTful interfaces.
Just hand Drowsy a hostname for the API to consume and you’re off to the races. Just look how easy it is to get started with the Gists API:
const github = drowsy(request, "https://api.github.com/");
github.getGists({
headers: {
"User-Agent": "Octo-app"
}
});
JSONPlaceholder is a free online REST API that you can use whenever you need some fake data. It’s great for tutorials, testing new libraries, sharing code examples, …
It comes with a set of 6 common resources. You know, the usual suspects like /posts and /comments. Prefer to use your own data? The whole thing is powered by json-server, which will get you up and running in 30 seconds-ish.
A fully automatic, framework-independent, RESTful PHP router component used in Scrawler
In this special rebroadcast of JS Party, Jerod and Suz talk with John Resig about how he’s using GraphQL at Khan Academy, some of the mistakes and successes using GraphQL, John’s feelings on jQuery, and community Q&A.
Jerod and Suz talk with John Resig about how he’s using GraphQL at Khan Academy, some of the mistakes and successes using GraphQL, John’s feelings on jQuery, and community Q&A.
NuSTER can be used as a RESTful NoSQL cache server, using HTTP POST/GET/DELETE to set/get/delete Key/Value object. It can be used as an internal NoSQL cache sits between your application and database like Memcached or Redis as well as a user facing NoSQL cache that sits between end user and your application. It supports headers, cookies, so you can store per-user data to same endpoint.
Justin Headley:
It took me a long time to find my own path of discovery. My hope is by sharing my story I might save you (and your API consumer) some heartache. Here’s what I’ve learned…
A fun post that culminates in the release of rest-hapi, a REST API generator.
Mihai A:
If we agree that a RESTful API should offer more or less the same functionality as the UI, then we can use the same tests for UI automation and for API testing, provided that we make the right abstractions and link them together properly – this will guarantee that the API is navigable and respects the HATEOAS principle.
HATEOAS, for those wondering, stands for Hypermedia As The Engine Of Application State, which is a fancy way of saying the REST application exposes its state (where resources are and how you can interact with them) via hypermedia embedded in API responses. The advantage of this is:
A REST client needs no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.
In practice, HATEOAS is often left off (which pretty much defeats the purpose of REST, but c’est la vie). The result is a “RESTful” API. Meaning it’s like REST but it ain’t really REST. I like well-designed RESTful APIs because they are easy to navigate logically, but true REST APIs don’t need to be navigated at all, which is way cooler.
But I digress, back to Mihai and this excellent post on testing:
The code that tests the UI should also test the API. It is achievable, provided that the architect pays as much attention on the tests as he does on the app’s code (which, sadly, is not always the case).
He goes on to show example code testing the GitHub API. Good stuff 👌
