Wow, it reminds me Telescope of neovim.
Adress API for germany. The data need to be gathered first.
An example of API testing in Cypress
It is a modern and convenient replacement for both the Websocket API and the higher-level libraries and services relying on it.
Mercure is especially useful to add streaming and asynchronous capabilities to REST and GraphQL APIs. It is a thin layer on top of HTTP and SSE
This is a super simple service for generating different HTTP codes.
It's useful for testing how your own scripts deal with varying responses.
Custom response headers can be set, as the HTTP status code.
2,529 APIs are listed at the time of consulting
Nice: a web service that creates a calendar event from a URL
Utile au besoin, l'État a publié le registre
Il existe aussi une #API dédiée https://api.gouv.fr/les-api/api_carto_codes_postaux
Create a command line interface from a REST API.
It seems powerful!
Joat uses a YAML file to define subcommands of two types: requests and scripts. Requests subcommands ease the interaction with a REST API and scripts combine multiple commands into a more convenient one.
Play the game by using API calls to deliver frets across the galaxy. One funny thing is the amount UIs users have built to get a grasp on the data :D
Endpoints:
- receive a quote that may induce existential dread
- estimate the percentage of life you have lived
- estimate the number of saturdays remaining
- estimate the number of people who will remember you in a given number of years
There is not a unstable then a stable phase, but 3 phases:
- the API is unstable as hell
- the API is mostly settled
- In the third phase, the API is fully stable, and no backwards-incompatible changes are expected.
We can name these:
- experimental (unstable)
- production-ready (still unstable, but you can budget-in a bounded amount of upgrade work)
- stable (no maintenance work is required)
Fast documentation generation for a backend in PHP
- Use Nouns to represent resources / Not Verbs
- Use Pluralized Nouns for resources
- Use hyphens (-) to improve the readability of URIs
- Use forward slashes (/) for hierarchy but not trailing forward slash (/)
- Avoid using file extensions
- Version your APIs:
http://api.example.com/v1
- Use query component to filter URI collection:
http://api.example.com/v1/store/employees?department=IT®ion=USA
An API that delivers data about Star wars
An API that delivers data about the pokemon world.
There is already 101 websites about fan-based websites!
Yes and that's exactly the problem! We aim to provide a single source of data that any number of other websites can consume and use.
Similar to the PokeAPI or the S(tar) W(ars) API.
This is an API.
As they provide static data, I see an efficient implementation with AstroJS where each route data are generated at compile time.
<div>
<div>
Name: Joe Blow
</div>
<div>
Email: joe@blow.com
</div>
<div>
<a href="/contacts/42/edit">Edit</a>
<a href="/contacts/42/email">Email</a>
<a href="/contacts/42/archive">Archive</a>
</div>
</div>
→
So, what makes this HTML/hypertext special? The answer is also simple: this bit of HTML encodes both the data about the contact as well as the actions available on that data, in the form of hyperlinks.
Formalizing REST APIs
My API is up to level 2 on the Richardson Maturity Model. So my API is more an HTTP+JSON RPC than Rest.
The short answer to this question is that HATEOAS isn’t a good fit for most modern use cases for APIs. That is why after almost 20 years, HATEOAS still hasn’t gained wide adoption among developers. GraphQL on the other hand is spreading like wildfire because it solves real-world problems. ‒ GraphQL and REST Level 3 (HATEOAS)
I feel this feeling too that something is wrong