Cleanup references to agreed changes in API #23
Conversation
| * Contents: Session Array (all sessions in request accepted for configuration). | ||
| * 300: | ||
| * Contents: Modified Session Array, with rejected or additional sessions. | ||
| * Contents: Session Array (all sessions in request accepted for configuration). Should not all the sessions be accepted, the response also contains a list of sessions and the respective errors. |
There was a problem hiding this comment.
(not blocking the merge) Is this a separate list, or will the rejected sessions be listed with status: "rejected"?
The second case makes sense to me, just confirming we are in alignment.
There was a problem hiding this comment.
The response contains 2 lists, the list of sessions and a list of errors. Either can be full-empty, partial-partial, empty-full to signify what happened to the collection of requested resources. The sum of both should match that of the request.
The error code was under question and I haven't found a conclusive source on what 2xx matches a partial accepted request (206 implies content ranges and 207 caldav) so opted to not overload existing 2xx with additional semantics. In the same way we expect initiators to match by some property each item of the response to each item of the request, the absence of one successful can be matched against the errors in the error list.
draft-ramseyer-grow-peering-api.md
Outdated
| @@ -359,11 +356,11 @@ On each call, there should be rate limits, allowed senders, and other optional r | |||
| * asn (requesting client's asn) | |||
| * request_id (optional, UUID of request) | |||
| * max_results (integer to indicate an upper bound for a given response page) | |||
| * next_token (opaque string to hint the query and last result returned when fetching a new page) | |||
| * next_token (opaque and optional string to hint the query and last result returned when fetching a previous page) | |||
There was a problem hiding this comment.
Doesn't next_token indicate the next page that we should fetch?
It comes from the previous page, but it links the next page, right?
There was a problem hiding this comment.
It does, the attribute itself is described as a token to convey that is abstract and opaque hence the explicit suffix.
There was a problem hiding this comment.
But doesn't the next token hint you to the next page, not the previous page?
Or is the intent here "give me the next page as directed from the 'next token' from the previous page"?
Maybe "opaque and optional string to hint the query and last result returned when fetching the following page" would be clearer?
There was a problem hiding this comment.
I see, let me be more verbose in the explanation to clarify it.
draft-ramseyer-grow-peering-api.md
Outdated
| * Response: | ||
| * 200: OK | ||
| * Contents: Session Array of sessions in request_id, if provided. Else, all existing and in-progress sessions between client ASN and server. | ||
| * next_token (opaque string for clients to use when retrieving a new page) | ||
| * next_token (opaque string for clients to use when retrieving a new page and which missing indicates no more pages to retrieve) |
caguado
force-pushed
the
contrib/crlsa/fixup-item-errors
branch
2 times, most recently
from
c4279bd to
413c179
Compare
This commit cleans up the references to the item_id and clarifies the HTTP return code for partial results.
caguado
force-pushed
the
contrib/crlsa/fixup-item-errors
branch
from
413c179 to
5d95efc
Compare
This commit cleans up the references to the item_id and clarifies the HTTP return code for partial results.