Skip to content

Introducing api.md#49

Open
vinaysrao1 wants to merge 3 commits intomainfrom
vinaysrao1-introducing-api-md
Open

Introducing api.md#49
vinaysrao1 wants to merge 3 commits intomainfrom
vinaysrao1-introducing-api-md

Conversation

@vinaysrao1
Copy link
Copy Markdown

Introducing API standards for ROOST software. It would be useful to get a conversation going on (1) OpenAPI as standard (2) Being standard ready immediately - Coop and Osprey aren't (3) Are we design first or code first re. API specification (4) should we have API standards only for external facing API or for internal APIs as well

@tgthorley
Copy link
Copy Markdown

How opinionated do you want to be in this documentation we could be much more specific about a bunch of topics, but it seems like the aim here is to be very general. Areas that it might be worth considering adding a little more guidance so that we don't have too much of a divergent approach across systems:

  • Authentication method(s) documented (and error responses)
  • Standard error schema (problem+json or equivalent)
  • Idempotency guidance for POST/PUT/PATCH
  • Naming conventions (paths, resources, fields)
  • Status code expectations

@vinaysrao1
Copy link
Copy Markdown
Author

How opinionated do you want to be in this documentation we could be much more specific about a bunch of topics, but it seems like the aim here is to be very general. Areas that it might be worth considering adding a little more guidance so that we don't have too much of a divergent approach across systems:

  • Authentication method(s) documented (and error responses)
  • Standard error schema (problem+json or equivalent)
  • Idempotency guidance for POST/PUT/PATCH
  • Naming conventions (paths, resources, fields)
  • Status code expectations

Thanks Tom.

Here are my thoughts

  1. Auth: The tools are self-hosted and internal to corp env. They have to accept specific auth mechanism of the org that implements. Even action and access levels should be reflected in RBACs that orgs are likely to set up at their security level.
  2. Error schema: I think this is useful. We are probably early in our journey. I do think it is imp to follow through.
  3. Idempotency: This is probably immediately useful and worth checking. I am inclined to add this.
  4. Naming conventions: Good to have, probably worth picking up with error schema. Is there is a good reference for this?
  5. Status code expectations: Probably worth taking up after idempotency.

Love to hear what others think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants