REST API Icon

REST API

A representational state transfer (REST) API is a way to provide compatibility between computer systems on the internet.
15 Stories
All Topics

Practices vinaysahni.com

Best practices for designing a pragmatic restful API

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 github.com

Use HTTP/2 Server Push to create fast and idiomatic client-driven REST APIs

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.

Changelog Interviews Changelog Interviews #360

Modern software is built on APIs

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.

SQLite github.com

Sqlite To Rest

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.

Iain J. Reid github.com

Drowsy - The laziest REST client you'll ever see

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"
  }
});

JSON jsonplaceholder.typicode.com

A fake online REST API for testing and prototyping

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.

project Icon github.com

NuSTER – an HTTP based, user facing, RESTful NoSQL server

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.

Mihai A amihaiemil.com

Test Driven Rest

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 👌

Player art
  0:00 / 0:00