Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some thoughts regarding the ALPS descriptors and its OAS output #14

Open
nnworkspace opened this issue Jan 30, 2021 · 1 comment
Open

Comments

@nnworkspace
Copy link

nnworkspace commented Jan 30, 2021

Hi,

the artifacts I'm refering to are:

Action-vocabularies such as "listCompanies", "filterCompanies", "readCompany" etc. are fine as is at a conceptual level. Though I'd like to have a way to describe which parameters are mandatory and which are optional.

The oas output, however, does not quite look like best practices in the HTTP RESTful world. In the output oas file:

  1. It is almost a convention now to use GET "/companies" for the conceptual action "listCompanies".
  2. For the action "filterCompanies", in the alps file, there are four query parameters. But in the output file, no query parameters are specified. In addition, it is better to use GET "/companies?legalName=blah&addressCountry=blah&...." instead of GET "filterCompanies?......"
  3. Similar comments for the create/update/delete actions.

A very concise book which explains the most current best practices can be found here:
https://cloud.google.com/files/apigee/apigee-web-api-design-the-missing-link-ebook.pdf

@nnworkspace nnworkspace changed the title Some thoughts regarding the alps descriptors and its aos output Some thoughts regarding the ALPS descriptors and its OAS output Jan 30, 2021
@mamund
Copy link
Owner

mamund commented Jan 31, 2021

@nnworkspace

thanks for the feedback. love to see your thoughts on this.

  1. ALPS is not a definition format like OAS, RAML, AsyncAPI, proto3, gQL, or other interface definition languages (IDLs). it is a much more abstract way to describe an interface. when @leonardr and i were first creating it, we were trying to create something that describes the problem space instead of the solution space. that's kind of esoteric and not meant as a "hand-wave".

  2. I totally agree that the OAS output is not within recommended standards. I got some of the same feedback on the lack of common practice for the protobuf version from @corntoole (who is spot on, as well).

i am very much looking for PRs on this to make it better. there are challenges here, but i don't think they're insurmountable.

finally, there is a mailing list where we can continue to talk about ALPS (https://groups.google.com/g/alps-io/) and we have open office hours every thursday at 14:30 UTC (not GMT) time. it would be great to connect and see where we can work together to make this all better.

-- @mamund

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

No branches or pull requests

2 participants