[Architecture] [APIM][300][Store] Feature to change password of an user

[Vithursa Mahendrarajah]

Hi all,
I am working on $subject in APIM 3.0.0. Planned flow of implementation is
as follows:

[image: new_password_mail.png]
We have SCIM API [1] for updating user-info. A separate REST API can be
implemented to provide the feature to change password by wrapping mentioned
SCIM API. The sample resource could be as,

PasswordChangeRequest:
title: Request for changing password
required:
  - username
  - currentPassword
  - newPassword
properties:
  username:
type: string
  currentPassword:
type: string
  newPassword:
type: string

Please provide your thoughts and feedback on this.

Thanks,
Vithursa
-- 
Vithursa Mahendrarajah
Software Engineer
WSO2 Inc. - http ://wso2.com
Mobile  : +947*66695643*


*  
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Design First APIs on APIM v3.0

[Nuwan Dias]

Hi Roshan,

Both options you mentioned are available. (1) is actually available even
today and (2) is something we are working on. I'm actually referring to a
3rd option which is where a user starts implementing an API on API Manager
using a Design First approach. In here the user first starts the
development by using our UIs to create the interface and then wants to take
control of the request and response message flows.

Thanks,
NuwanD.

On Thu, Aug 16, 2018 at 10:18 AM Uvindra Dias Jayasinha 
wrote:

> +1 for the approach suggested by NuwanD, this gives us a best of both
> worlds scenario separating user code from generated code.
>
> I believe we can even handle Roshan's requirement for non technical users
> in this way. Uploading Ballerina functions that will be associated with a
> given resource can be an optional step(For injecting custom API logic). By
> default an API will simply act as a pass through API proxy for the endpoint
> that it is fronting. This allows non technical users to define API proxies
> for their existing APIs without writing any code. For all other
> scenarios(mediation, transformation, implementing the API on the Ballerina
> gateway itself, etc.) you will need to get your hands dirty.
>
>
> On 15 August 2018 at 20:12, Nuwan Dias  wrote:
>
>> Hi,
>>
>> This is regarding the implementation of APIs on API Manager v3.0 using a
>> Design First Approach. The API Publisher Portal of API Manager will have
>> the UI constructs required to design the interface of the API including the
>> resource paths, verbs, base paths, etc. This version of API Manager uses
>> Ballerina as its API implementation language. When it comes to implementing
>> the API logic, our plan was to allow users to edit the full Ballerina
>> source of the corresponding API. The sequence of actions in performing this
>> operation would be as follows.
>>
>> 1. User creates API definition (interface) using UI.
>> 2. Server code gens the Ballerina source corresponding to the above
>> definition.
>> 3. User edits the Ballerina source of the corresponding resources.
>>
>> Since this leads to a situation where the user edits an auto generated
>> code and re-auto generation leads to complications related to merging auto
>> generated code with user written code, this has led to rethinking how to
>> want to enable implementation of APIs from the API publisher.
>>
>> An alternative approach is to let the user implement Ballerina functions
>> offline and upload them to the API Manager. These functions should be
>> written according to a function template (signature). They can then be
>> linked to a particular resource. A function each can be linked for
>> processing the request and for processing the response. This is similar to
>> the model that we have today of uploading sequences for a given API, but
>> more powerful in terms of capability due to how the Gateway engine behaves
>> (Synapse vs Ballerina). This way a user does not edit auto generated code.
>> The code gen process would link the auto generated code with the user
>> uploaded code and create a consolidated Ballerina source to be deployed on
>> the Gateways.
>>
>> Another advantage here is that this model does not require us to have a
>> web based Ballerina editor. Users defining functions could use any editor
>> supported by Ballerina offline.
>>
>> I am opening up this idea for thoughts and suggestions.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Director - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Nuwan Dias

Director - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture