Giters

opengeospatial / OGC-Web-API-Guidelines

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consolidate the SecureDimensions branch in the master. Focus on WebAPI or in RESTful resources?

joanma747 opened this issue · comments

commented

I believe we need converge on a single document for the discussion in September. I believe there are significant contributions in the SecureDimensions branch that can be incorporated in the master.

The main difference I see is that the "master" is more focused on RESTful resources and the "SecureDimensions" branch more on WebAPI. I believe we need to avoid falling into REST and non-REST discussion again so I personally recommend to remove all reference to REST. This does not preclude that a good WebAPI should consider an analysis of the "resources" it considers and a clear separation between a requesting a resource and the response of the "filter" on a resource (that is not necessarily a resource but is a perfectly acceptable beast).

How can we get back to a single master branch by incorporating what is great from the "SecureDimensions" branch in the master that needs to be the "everybody's" branch?

commented

I disagree with Principles 17 and 18 as modified in the Secure Dimensions branch. The updates miss the point these Principles are trying to make (see #19 and #20). Beyond than, I support merging into a single branch.

commented

I'm happy to purge the word REST from the OGC vocabulary. But we do need a way to distinguish resource-oriented architecture patterns from service-oriented architecture patterns. Perhaps we should adopt the ROA vs SOA terminology. OpenAPI becomes a "standard" for describing ROA APIs.

Then we can consider two Guidance documents:

  1. API Guidance (based on OpenAPI)
  2. Resource Guidance (including standards for the path templates and encodings)
commented

I fully agree with the use of ROA style that we inaugurated in the WMTS 1.0 standard in the Valencia's TC. To me ROA has no definition problem.

I'm not sure if we will be able to separate API Guidance and Resource Guidance since both relay on the need to defined resources and URL templates but that is possible way forward.

Please tell us how to improve principle 17 and 18 in the right direction. I have modified 17 already.

commented

we believe this is now addressed in master