Dear Pamoda,
- Why do you need both, limitWithoutDefaultQueryParam as well
as limitQueryParam? Won't limitQueryParam do what we need? (same question
for other parameters like offset etc)
- Parameters like sortByQueryParam is not supported in the current
version (according to the Swagger file). What response do we return if such
a parameter is passed in the query string: "400 Bad Request" or "501 Not
Implemented"? Wouldn't it be more convenient for an API user (or reviewer)
to not document parameters that are not (yet) supported?
- POST /applications has a JSON document as payload.
In contrast, POST /applications/import supports an XML file, which is
passed as a binary file in the payload
- Is this a Base64 encoded binara? If YES, we should say so.
Otherwise: I don't understand :-)
- If XML is still important for us, why doesn't POST /applications
not support XML as payload too?
So, the underlying observation is that it seems to be strange (to me) to
invent an *import* API for creating new application from XML documents,
while a new application is created based on a JSON document via a different
API. The semantics of the APIs is the same, only the representation of the
payload is different... Can't we combine the two APIs supporting different
types of payloads?
- PUT /applications/import is used to *substitute* an application that
has been provided by means of an XML document before. But an application
that has been created based on a JSON document can be (partially) updated
via PATCH /applications/{applicationId}. Again, the representation of the
resource determines how it can be manipulated. This seems to be strange (to
me) and not consistent with the REST paradigm.
- Is there any documentation about the semantics of the PATCH model (ie.
what is the language I use to specify what is updated; what if some updates
can be applied, some others not [i.e. is there any notion of "atomicity" of
updates])?
Thanks!
Best regards,
Frank
Am Mi., 1. Apr. 2020 um 16:25 Uhr schrieb Pamoda Wimalasiri <[email protected]
>:
> Hi all,
>
> We have introduced a set of new REST APIs for managing the application
> templates. These new application template management APIs are added as an
> improvement to the Application Management API. With these APIs, the
> frequently used application configurations can be saved as a template so
> that they can be reused when creating a new application.
>
> Following new endpoints are added for Application Template Management.
>
> - *GET */applications/templates
> - Retrieve all the application templates created for a tenant.
> - *POST* /applications/templates
> - Create a new application template
> - *GET */applications/templates/{template-id}
> - Get the application template information when given the template
> id
> - *PUT* /applications/templates/{template-id}
> - Update an application template when given with the template id
> - *DELETE* /applications/templates/{template-id}
> - Delete the application template with the given template id
>
> The swagger definition of these API can be found here
> <https://app.swaggerhub.com/apis/pamoda/wso-2_identity_server_application_management_rest_api/v1#/Application%20Templates>
> .[1]
>
> Application Template Management service is implemented using the Template
> Manager OSGi services. The implementation details related to the
> Application Template Management API can be found here
> <https://github.com/wso2/identity-api-server/commit/d47979934d852cd47d44f8ece1129da1b8e0f328>
> [2].
>
> [1]
> https://app.swaggerhub.com/apis/pamoda/wso-2_identity_server_application_management_rest_api/v1#/Application%20Templates
> [2]
> https://github.com/wso2/identity-api-server/commit/d47979934d852cd47d44f8ece1129da1b8e0f328
>
> Thanks,
> Pamoda
> --
> *Pamoda Wimalasiri | *Senior Software Engineer | WSO2 Inc.
> (m) +94713705814 | (w) +94112145345 | (e) [email protected]
>
> <http://wso2.com/signature>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
