Reference Specification for API first approach

[wtrocki]

Landing as first version/draft for discussion. Some styles/links will be improved further. I have also draft blog post to accompany this spec.

[mhdawson]

@wtrocki I pushed a commit with a substantial edit (I could not easily figure out how to do a PR against your PR).

We can discard if the edit does not make sense to you.

[wtrocki]

Provided changes looks good, but I'm not 100% sure if we want to rebrand this as API guide. Maybe we can find sweet spot between "building your API" vs "API first".

My only concern is that many developers can look into this chapter as "Building your API with express" and it will find very opiniated and unfamiliar concept for them to look at.

[mhdawson]

@wtrocki maybe we can add some additional words. The sections we have are "the team has had success with X". If our main success is with API first using express then it makes sense that this is what is in this section. Instead of narrowing the title I think it would be better to expand the content if there are other approaches/tools that we have used regularly and have had success with. I do think we want a topic with our guideance/experience with how to build a REST API.

[mhdawson]

The other thing I should have mentioned is that we should add the referenced modules to the npcheck.json file.

[wtrocki]

npcheck.json file.

npmcheck.json seems to be non functional right now and failing on build. Can I get help with adding those packages and fixing build? See #94

[mhdawson]

Getting npcheck working again on the repo is a priority. There is some ongoing discussion here: https://github.com/nodeshift/npcheck/pu](https://github.com/nodeshift/npcheck/pull/88. @richardlau has been out the last week though and I've had lots of other things so have had time to look. We should try to make sure we resolve in some way next week.

[wtrocki]

Done npmcheck.json Can we get this merged?

[wtrocki]

Need help with npmcheck

[helio-frota]

probably need to add these 2 packages in npcheck.json?

"tslib@2.3.1" ---- package which is under the non-acceptable license "0BSD". "caniuse-lite@1.0.30001282" ---- package which is under the non-acceptable license "CC-BY-4.0".

[wtrocki]

@helio-frota can you help me with those. I did not added those packages myself.

[helio-frota]

@wtrocki I think you just need to update npcheck.json with

stoplight/prism-http and openapi-editor same as you did for the others to exclude the licenses :+1:

(47): The module "@stoplight/prism-http" depends on the "tslib@2.3.1" package which is under the non-acceptable license "0BSD". - ERROR
(48): The module "@stoplight/prism-http" is not tested by community CITGM runs.
...
(56): The module "openapi-editor" depends on the "caniuse-lite@1.0.30001282" package which is under the non-acceptable license "CC-BY-4.0". - ERROR

like this https://github.com/nodeshift/nodejs-reference-architecture/pull/93/files#diff-b43bb8fc5cc3dd0ad9082a957b458e42e6d93d373577c112484736c3199fbea4R194

[mhdawson]

@wtrocki looked at the remaining 2 licence failure reports and the overall addition to the rules. 0BSD seems fine to me as it is less restrictive than the BSD ones we allow by default and the other 2 (Python-2.0 and CC-BY-4.0) we've already allowed exceptions for other components since they don't look like they'd be an issue.

I went ahead and update to allow thosteand the "due dilligence" is now green.

[wtrocki]

@mhdawson thank you so much! Let's merge that. I will

• Update website
• follow up with blog post to redhat-developers.

[mhdawson]

Pushed a commit on main branch to rename to "REST API Development" based on what we agreed in ref arch meeting this week.