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

JSON API documentation improvements #4173

Merged
merged 1 commit into from
Jan 23, 2020
Merged

JSON API documentation improvements #4173

merged 1 commit into from
Jan 23, 2020

Conversation

leo-da
Copy link
Contributor

@leo-da leo-da commented Jan 22, 2020

Closes: #3732

Pull Request Checklist

  • Read and understand the contribution guidelines
  • Include appropriate tests
  • Set a descriptive title and thorough description
  • Add a reference to the issue this PR will solve, if appropriate
  • Include changelog additions in one or more commit message bodies between the CHANGELOG_BEGIN and CHANGELOG_END tags
  • Normal production system change, include purpose of change in description

NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with /AzurePipelines run to
trigger the build.

- exercising choices on contracts, and
- querying the current active contract set.
- create contract,
- fetch active contract by contract ID or contract key,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the description here informal, describing categories of functionality not enumerating features; fetch is already covered by "query the current active contract set".


application/json body, formatted according to the :doc:`search-query-language`:
If client's HTTP request reaches an API endpoint, the corresponding response will always contain a JSON object with ``status`` field and either ``errors`` or ``result``:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If client's HTTP request reaches an API endpoint, the corresponding response will always contain a JSON object with ``status`` field and either ``errors`` or ``result``:
If client's HTTP GET or POST request reaches an API endpoint, the corresponding response will always contain a JSON object with ``status`` field and either ``errors`` or ``result``:

Copy link
Contributor

@hurryabit hurryabit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely an improvement. Thanks.


List all currently active contracts for all known templates. Note that the retrieved contracts do not get persisted into query store database.
See the following blog post for more details: `REST API Error Codes 101 <https://blog.restcase.com/rest-api-error-codes-101/>`_.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels strange to me to start with a link to an external blog post. IMO, there should be at least a sentence stating that we use standard REST API error codes or something similar.

}
- ``status`` -- a JSON Number which matches the HTTP response status code returned in the HTTP header,
- ``errors`` -- a JSON array of strings, each string represents one error,
- ``result`` -- a JSON object or JSON array, representing one or many results.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have warnings as well now.

+ ``"<package ID>:<module>:<entity>"`` or
+ ``"<module>:<entity>"`` if contract template can be uniquely identified by it's module and entity name.

- ``argument`` field contains contract fields as defined in the DAML template and formatted according to :doc:`lf-value-specification`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't we renamed this to payload? If not, we should in order to make it consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hurryabit it is renamed only in the response. See #3826 :

I suggest we rename the argument field of the contracts you receive from the JSON API to payload.

This particular JSON is a create command, a request sent to JSON API.

Copy link
Contributor Author

@leo-da leo-da Jan 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you want to rename argument to the payload in the requests, this should be addressed in #4189.

@@ -569,26 +549,29 @@ Contract Found Response
}
}

Lookup by Contract Key
----------------------
Fetch Contract by Contract Key
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Fetch Contract by Contract Key
Fetch Contract by Key

Contract Search, All Templates
==============================

List all currently active contracts for all known templates. Note that the retrieved contracts do not get persisted into query store database.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any explanation of what the "query store database" is? I couldn't find any.

@leo-da leo-da requested a review from S11001001 January 23, 2020 17:18
Document error handling

Document query store

CHANGELOG_BEGIN
CHANGELOG_END
@leo-da leo-da force-pushed the leo-3732-json-api-doc branch from faca5fb to b8cf409 Compare January 23, 2020 19:01
@leo-da leo-da merged commit 78b2985 into master Jan 23, 2020
@leo-da leo-da deleted the leo-3732-json-api-doc branch January 23, 2020 19:54
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.

Better documentation of the JSON API endpoints
3 participants