7 Commits (69ebfd6f037f8d51709770cc36d266bb86cf950d)

Author	SHA1	Message	Date
Nick Fagerlund	7a8dd326c6	website: Language: Update links to moved pages	5 years ago
Martin Atkins	7ccaee1018	website: Fix inconsistencies in the registry protocol page ... Some hasty, incorrect merge conflict fixing caused this page to have a strange mix of terminology between "system" and "provider". Along with that, there were also several editorial errors caused by text on this page having originally been derived from the provider registry documentation. This documentation will now consistently talk about being a module registry protocol rather than a provider registry protocol, and it will consistently use the term "system" as a generic term for the final part of the module source address, aside from noting that there is an optional convention to name it after the "type" part of an official provider when possible.	5 years ago
Andrew Fitzgerald	8c82b3f6a0	Remove 'system' references from module registry protocol docs.	5 years ago
alevinetx	66393bb62e	website: Update module-registry-protocol.html.md (#26639) ... * Update module-registry-protocol.html.md 1: There is a mismatch in the segment labels for the version query URL (system vs provider) 2: There is a discrepancy between the documentation and the actual generated request for retrieving module source code (URL segments 4 vs 3) - There is no segment for "provider" * Update module-registry-protocol.html.md Changed ```:system``` to ```:provider``` for versions and source API URLs	6 years ago
Nick Fagerlund	2ffb71bcee	website: Fix several broken links (#25808)	6 years ago
Martin Atkins	80a4bfbf27	website: New navigation items for the module and provider registry specs	6 years ago
Martin Atkins	63639defe9	website: Separate docs for the module registry protocol ... We previously had the module registry protocol documented only as an undefined subset of the full API of the official registry implementation. However, the vast majority of endpoints documented in the official API docs are not needed for a headless third-party module registry that only intends to make modules available to Terraform CLI. To make this clearer to potential third-party implementors, and also for consistency with how the provider registry protocol is now documented, here we create a new page to describe the subset required for all registries, and then explain in the docs for the offical API that potential third-party implementors should refer to the new page instead. The longer page describing the full API of the official implementations remains for those who wish to write clients for that API, because it is part of the API surface area for Terraform Cloud and Terraform Enterprise. I also took this opportunity to address the fact that module addresses don't really contain "provider names" at all, but rather than the fourth field in the address is _conventionally_ an official provider name but can really be any string that serves to differentiate multiple implementations of the same abstraction. The new docs therefore refer to this field as "system" rather than "provider".	6 years ago