Fast documentation generation for a backend in PHP

1. Use Nouns to represent resources / Not Verbs
2. Use Pluralized Nouns for resources
3. Use hyphens (-) to improve the readability of URIs
4. Use forward slashes (/) for hierarchy but not trailing forward slash (/)
5. Avoid using file extensions
6. Version your APIs: http://api.example.com/v1
7. Use query component to filter URI collection: http://api.example.com/v1/store/employees?department=IT&region=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.

Github: https://github.com/PokeAPI/pokeapi

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.

Github: https://github.com/KostaSav/hp-api

<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

1. Be consistent
2. Use ISO 8601 UTC dates
3. Make an exception for public endpoints instead of
4. Provide a health check endpoint: GET /health
5. Version the API
6. Accept API key authentication
7. Use reasonable HTTP status codes
8. Use reasonable HTTP methods
9. Use self-explanatory, simple names: Most endpoints are resource-oriented and should be named that way.
10. Use standardized error responses (the same error structure)
11. Return created resources upon POST
12. Prefer PATH over PUT: full update of a resource is rare
13. Be as specific as possible
14. Use pagination
15. Allow expanding resources

Tracks plane around the world. It offers an API :)

Develop an API that is fast :)
Everything is built in: Swagger or OpenAPI, including the tests.

Here a quickstart

The doc is here: https://prestigemad.com/docs/

Useful to find rhymes, word alike, etc...

Looks cool :)

Utiliser le workflow de Github pour avoir un retour sur la disponibilité d'un site web 👍

avec la "doc": http://api.warriordudimanche.net/iconeleon/?help

• https://genderize.io – Pour déterminer le genre
• https://agify.io – Pour déterminer l’age
• https://nationalize.io – Pour déterminer la nationalité.

Une série des meilleures pratiques pour la création d'API
La suite devrait arriver prochainement.

Easy and simple.

Reminder : URL shortener are only for temporary use. The original URL still has to be indicated next to the shorten one in case the service disappears.

(via https://korben.info/la-liste-ultime-des-api-publiques.html)

under one's arm