Re: [Dev] APIM REST API with Subscription Creation Workflows
Hi Frank, Thanks for the clarification. I have created [1] to track the issue. Thank you. Malintha [1] https://wso2.org/jira/browse/APIMANAGER-4295 On Sat, Nov 28, 2015 at 6:57 PM, Frank Leymann wrote: > Hi Malintha, > > using 202 Accepted without returning a Content-Location header that the > client can poll is no real solution. This is because the client needs a URL > to poll for the actual status whenever the client wants. If this is to > much to implement for the next release, we should note that issue and > implement it for the release after the next. > > > Best regards, > Frank > > 2015-11-27 17:20 GMT+01:00 Malintha Amarasinghe : > >> Hi All, >> >> Thanks a lot for all the suggestions. >> >> Hi Frank, >> >> According to your suggestion, is it OK to change the response type 202 >> Accepted, but keeping the response as it is?. We might be able to check if >> the status is ON_HOLD and change the response code accordingly to 202 >> Accepted. If the status is UNBLOCKED, we can set the status code to 201 >> Created. Would this solution be OK for the moment till we implement this >> properly? >> >> Thank you, >> Malintha >> >> On Fri, Nov 27, 2015 at 3:11 PM, Frank Leymann wrote: >> >>> +1 on REST APIs for BPS. >>> >>> I'll be in Colombo for WSO2Conn Asia in February. I know it's a long >>> time until than, but I suggest to have a joint design session on that >>> subject - let me know if we should pursue this... >>> >>> >>> Best regards, >>> Frank >>> >>> 2015-11-27 6:31 GMT+01:00 Sanjeewa Malalgoda : >>> On Thu, Nov 26, 2015 at 11:28 PM, Joseph Fonseka wrote: > Hi All > > Did some background check on possibility of having a task resources. > > Nandika informed us about the REST service support in BPS. As of now > BPEL implementation in BPS only deals with SOAP services and BPMN has a > REST API. So this will give us few complications. > > 1. IMO task resource should be provided from BPS which we can point to > from our REST API. > 2. Even though BPMN has a REST service currently our workflows works > with BPEL which require us to do a migration to BPMN if we want to use the > REST API. > 3. Given the time I do not think switching to BPMN is possible ( Even > if we decides that is the correct thing to do ) and we need to think about > existing customers. > 4. Or implement REST support to BPEL ( again hard to do with the time > line ) > > That leads us to following options. > 1. Implement REST API to fetch task resources in API manager. > 2. Send the workflow related data in a resource it self ( Or we can > send it in a header ). > 3. Postpone the workflow integration with REST API to next release. ( > We will be still supporting workflows but REST API will not send workflow > related data ) > Yes i also agree with you Jo. The reason is we have very little time to complete this task and it will not allow us to spend enough time on this. And By the time we plan next release we will have some better solution from BPS side. As we discussed we may wrap BPEL admin services with REST API. But it will not added value to both products. Next release we need to come to conclusion about BPMN. If that is possible then we can use same rest API. Thanks, sanjeewa. > > I favor 3rd option since that will give us enough time to properly > evaluate the options and come up with a good design. > > WDYT? > > Thanks > Jo > > > > > On Thu, Nov 26, 2015 at 7:54 PM, Frank Leymann wrote: > >> Dear all, >> >> why do we want to express by returning "ON_HOLD"? I assume (correct >> me if I am wrong) we want to say that the resource has not yet been >> created >> because the workflow is still running: it depends on the result of the >> workflow whether finally the subscription will be made or not. >> >> If this is the case, we must not return a "201 Created" because the >> resource is not created. But we have to return "201 Accepted" with a task >> resource in the body of the response; also, a Content-Location header has >> to be returned that contains the URL of the task resource; this URL will >> be >> used by the client to check changes in the status of the task (i.e. the >> workflow). >> >> If the long running request (the workflow) completed successfully, a >> GET on the URL of the task resource will return with "303 See Other" and >> a >> Location header field containing the URL of the created resource (i.e. >> the >> subscription). >> >> It the long running request completes UNsuccessfull, a GET on the URL >> of the task resource will return a "200 OK" BUT the task resource (i.e. >> the >> information about the status of the workflow) in the body will contain
Re: [Dev] APIM REST API with Subscription Creation Workflows
Hi All,
Thanks a lot for all the suggestions.
Hi Frank,
According to your suggestion, is it OK to change the response type 202
Accepted, but keeping the response as it is?. We might be able to check if
the status is ON_HOLD and change the response code accordingly to 202
Accepted. If the status is UNBLOCKED, we can set the status code to 201
Created. Would this solution be OK for the moment till we implement this
properly?
Thank you,
Malintha
On Fri, Nov 27, 2015 at 3:11 PM, Frank Leymann wrote:
> +1 on REST APIs for BPS.
>
> I'll be in Colombo for WSO2Conn Asia in February. I know it's a long time
> until than, but I suggest to have a joint design session on that subject -
> let me know if we should pursue this...
>
>
> Best regards,
> Frank
>
> 2015-11-27 6:31 GMT+01:00 Sanjeewa Malalgoda :
>
>>
>>
>> On Thu, Nov 26, 2015 at 11:28 PM, Joseph Fonseka wrote:
>>
>>> Hi All
>>>
>>> Did some background check on possibility of having a task resources.
>>>
>>> Nandika informed us about the REST service support in BPS. As of now
>>> BPEL implementation in BPS only deals with SOAP services and BPMN has a
>>> REST API. So this will give us few complications.
>>>
>>> 1. IMO task resource should be provided from BPS which we can point to
>>> from our REST API.
>>> 2. Even though BPMN has a REST service currently our workflows works
>>> with BPEL which require us to do a migration to BPMN if we want to use the
>>> REST API.
>>> 3. Given the time I do not think switching to BPMN is possible ( Even if
>>> we decides that is the correct thing to do ) and we need to think about
>>> existing customers.
>>> 4. Or implement REST support to BPEL ( again hard to do with the time
>>> line )
>>>
>>> That leads us to following options.
>>> 1. Implement REST API to fetch task resources in API manager.
>>> 2. Send the workflow related data in a resource it self ( Or we can send
>>> it in a header ).
>>> 3. Postpone the workflow integration with REST API to next release. ( We
>>> will be still supporting workflows but REST API will not send workflow
>>> related data )
>>>
>> Yes i also agree with you Jo. The reason is we have very little time to
>> complete this task and it will not allow us to spend enough time on this.
>> And By the time we plan next release we will have some better solution
>> from BPS side.
>> As we discussed we may wrap BPEL admin services with REST API. But it
>> will not added value to both products.
>> Next release we need to come to conclusion about BPMN. If that is
>> possible then we can use same rest API.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>>
>>> I favor 3rd option since that will give us enough time to properly
>>> evaluate the options and come up with a good design.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> Jo
>>>
>>>
>>>
>>>
>>> On Thu, Nov 26, 2015 at 7:54 PM, Frank Leymann wrote:
>>>
Dear all,
why do we want to express by returning "ON_HOLD"? I assume (correct me
if I am wrong) we want to say that the resource has not yet been created
because the workflow is still running: it depends on the result of the
workflow whether finally the subscription will be made or not.
If this is the case, we must not return a "201 Created" because the
resource is not created. But we have to return "201 Accepted" with a task
resource in the body of the response; also, a Content-Location header has
to be returned that contains the URL of the task resource; this URL will be
used by the client to check changes in the status of the task (i.e. the
workflow).
If the long running request (the workflow) completed successfully, a
GET on the URL of the task resource will return with "303 See Other" and a
Location header field containing the URL of the created resource (i.e. the
subscription).
It the long running request completes UNsuccessfull, a GET on the URL
of the task resource will return a "200 OK" BUT the task resource (i.e. the
information about the status of the workflow) in the body will contain the
information that the request failed together with other information we deem
appropriate.
Best regards,
Frank
2015-11-24 14:21 GMT+01:00 Nuwan Dias :
>
>
> On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe <
> malint...@wso2.com> wrote:
>
>> Hi All,
>>
>> I configured the subscription creation workflow and tested it with
>> the current implementation of the REST API.
>>
>> When we add a subscription in normal scenario we get the following
>> response.
>>
>> *Request*:
>>
>> POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1
>>
>> {
>> "tier": "Silver",
>> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
>> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
>> }
>>
>>
>> *Response:*
>>
>> HTTP/1.1 *201* Created
>>
Re: [Dev] APIM REST API with Subscription Creation Workflows
Hi all,
Workflows aren't tied to BPS (BPEL nor BPMN). BPS is our workflow engine of
choice for the OOTB implementation.
Someone could well write a workflow extension in java which says, "your
subscription would be active/created in 24 hours just because I want it to
be that way".
We could drop the workflow support for the immediate release, but our
solution to the problem shouldn't be tied with BPS.
Thanks,
NuwanD.
On Fri, Nov 27, 2015 at 11:01 AM, Sanjeewa Malalgoda
wrote:
>
>
> On Thu, Nov 26, 2015 at 11:28 PM, Joseph Fonseka wrote:
>
>> Hi All
>>
>> Did some background check on possibility of having a task resources.
>>
>> Nandika informed us about the REST service support in BPS. As of now BPEL
>> implementation in BPS only deals with SOAP services and BPMN has a REST
>> API. So this will give us few complications.
>>
>> 1. IMO task resource should be provided from BPS which we can point to
>> from our REST API.
>> 2. Even though BPMN has a REST service currently our workflows works with
>> BPEL which require us to do a migration to BPMN if we want to use the REST
>> API.
>> 3. Given the time I do not think switching to BPMN is possible ( Even if
>> we decides that is the correct thing to do ) and we need to think about
>> existing customers.
>> 4. Or implement REST support to BPEL ( again hard to do with the time
>> line )
>>
>> That leads us to following options.
>> 1. Implement REST API to fetch task resources in API manager.
>> 2. Send the workflow related data in a resource it self ( Or we can send
>> it in a header ).
>> 3. Postpone the workflow integration with REST API to next release. ( We
>> will be still supporting workflows but REST API will not send workflow
>> related data )
>>
> Yes i also agree with you Jo. The reason is we have very little time to
> complete this task and it will not allow us to spend enough time on this.
> And By the time we plan next release we will have some better solution
> from BPS side.
> As we discussed we may wrap BPEL admin services with REST API. But it will
> not added value to both products.
> Next release we need to come to conclusion about BPMN. If that is possible
> then we can use same rest API.
>
> Thanks,
> sanjeewa.
>
>
>>
>> I favor 3rd option since that will give us enough time to properly
>> evaluate the options and come up with a good design.
>>
>> WDYT?
>>
>> Thanks
>> Jo
>>
>>
>>
>>
>> On Thu, Nov 26, 2015 at 7:54 PM, Frank Leymann wrote:
>>
>>> Dear all,
>>>
>>> why do we want to express by returning "ON_HOLD"? I assume (correct me
>>> if I am wrong) we want to say that the resource has not yet been created
>>> because the workflow is still running: it depends on the result of the
>>> workflow whether finally the subscription will be made or not.
>>>
>>> If this is the case, we must not return a "201 Created" because the
>>> resource is not created. But we have to return "201 Accepted" with a task
>>> resource in the body of the response; also, a Content-Location header has
>>> to be returned that contains the URL of the task resource; this URL will be
>>> used by the client to check changes in the status of the task (i.e. the
>>> workflow).
>>>
>>> If the long running request (the workflow) completed successfully, a GET
>>> on the URL of the task resource will return with "303 See Other" and a
>>> Location header field containing the URL of the created resource (i.e. the
>>> subscription).
>>>
>>> It the long running request completes UNsuccessfull, a GET on the URL of
>>> the task resource will return a "200 OK" BUT the task resource (i.e. the
>>> information about the status of the workflow) in the body will contain the
>>> information that the request failed together with other information we deem
>>> appropriate.
>>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-11-24 14:21 GMT+01:00 Nuwan Dias :
>>>
On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe <
malint...@wso2.com> wrote:
> Hi All,
>
> I configured the subscription creation workflow and tested it with the
> current implementation of the REST API.
>
> When we add a subscription in normal scenario we get the following
> response.
>
> *Request*:
>
> POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1
>
> {
> "tier": "Silver",
> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
> }
>
>
> *Response:*
>
> HTTP/1.1 *201* Created
>
> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
> 63ab53d3-0cb7-46df-8ce9-cd84f2882b27
> Content-Type: application/json
>
>
> {
> "tier": "Silver",
> "subscriptionId": "63ab53d3-0cb7-46df-8ce9-cd84f2882b27",
> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
> *"status": "UNBLOCKED"*
> }
>>
Re: [Dev] APIM REST API with Subscription Creation Workflows
On Thu, Nov 26, 2015 at 11:28 PM, Joseph Fonseka wrote:
> Hi All
>
> Did some background check on possibility of having a task resources.
>
> Nandika informed us about the REST service support in BPS. As of now BPEL
> implementation in BPS only deals with SOAP services and BPMN has a REST
> API. So this will give us few complications.
>
> 1. IMO task resource should be provided from BPS which we can point to
> from our REST API.
> 2. Even though BPMN has a REST service currently our workflows works with
> BPEL which require us to do a migration to BPMN if we want to use the REST
> API.
> 3. Given the time I do not think switching to BPMN is possible ( Even if
> we decides that is the correct thing to do ) and we need to think about
> existing customers.
> 4. Or implement REST support to BPEL ( again hard to do with the time line
> )
>
> That leads us to following options.
> 1. Implement REST API to fetch task resources in API manager.
> 2. Send the workflow related data in a resource it self ( Or we can send
> it in a header ).
> 3. Postpone the workflow integration with REST API to next release. ( We
> will be still supporting workflows but REST API will not send workflow
> related data )
>
Yes i also agree with you Jo. The reason is we have very little time to
complete this task and it will not allow us to spend enough time on this.
And By the time we plan next release we will have some better solution from
BPS side.
As we discussed we may wrap BPEL admin services with REST API. But it will
not added value to both products.
Next release we need to come to conclusion about BPMN. If that is possible
then we can use same rest API.
Thanks,
sanjeewa.
>
> I favor 3rd option since that will give us enough time to properly
> evaluate the options and come up with a good design.
>
> WDYT?
>
> Thanks
> Jo
>
>
>
>
> On Thu, Nov 26, 2015 at 7:54 PM, Frank Leymann wrote:
>
>> Dear all,
>>
>> why do we want to express by returning "ON_HOLD"? I assume (correct me
>> if I am wrong) we want to say that the resource has not yet been created
>> because the workflow is still running: it depends on the result of the
>> workflow whether finally the subscription will be made or not.
>>
>> If this is the case, we must not return a "201 Created" because the
>> resource is not created. But we have to return "201 Accepted" with a task
>> resource in the body of the response; also, a Content-Location header has
>> to be returned that contains the URL of the task resource; this URL will be
>> used by the client to check changes in the status of the task (i.e. the
>> workflow).
>>
>> If the long running request (the workflow) completed successfully, a GET
>> on the URL of the task resource will return with "303 See Other" and a
>> Location header field containing the URL of the created resource (i.e. the
>> subscription).
>>
>> It the long running request completes UNsuccessfull, a GET on the URL of
>> the task resource will return a "200 OK" BUT the task resource (i.e. the
>> information about the status of the workflow) in the body will contain the
>> information that the request failed together with other information we deem
>> appropriate.
>>
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-11-24 14:21 GMT+01:00 Nuwan Dias :
>>
>>>
>>>
>>> On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe <
>>> malint...@wso2.com> wrote:
>>>
Hi All,
I configured the subscription creation workflow and tested it with the
current implementation of the REST API.
When we add a subscription in normal scenario we get the following
response.
*Request*:
POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1
{
"tier": "Silver",
"apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
}
*Response:*
HTTP/1.1 *201* Created
Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
63ab53d3-0cb7-46df-8ce9-cd84f2882b27
Content-Type: application/json
{
"tier": "Silver",
"subscriptionId": "63ab53d3-0cb7-46df-8ce9-cd84f2882b27",
"apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
*"status": "UNBLOCKED"*
}
When we have a subscription creation workflow enabled, we receive a
response like follow.
HTTP/1.1 *201* Created
Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
def79733-e55e-464f-9630-c1ae595344f2
Content-Type: application/json
{
"subscriptionId": "def79733-e55e-464f-9630-c1ae595344f2",
"apiId": "admin-pubApi-1.0",
"tier": "Silver",
"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
*"status": "ON_HOLD"*
}
Here we can see that the status is ON_HOLD. In this case we can also
see s
Re: [Dev] APIM REST API with Subscription Creation Workflows
Hi All
Did some background check on possibility of having a task resources.
Nandika informed us about the REST service support in BPS. As of now BPEL
implementation in BPS only deals with SOAP services and BPMN has a REST
API. So this will give us few complications.
1. IMO task resource should be provided from BPS which we can point to from
our REST API.
2. Even though BPMN has a REST service currently our workflows works with
BPEL which require us to do a migration to BPMN if we want to use the REST
API.
3. Given the time I do not think switching to BPMN is possible ( Even if we
decides that is the correct thing to do ) and we need to think about
existing customers.
4. Or implement REST support to BPEL ( again hard to do with the time line )
That leads us to following options.
1. Implement REST API to fetch task resources in API manager.
2. Send the workflow related data in a resource it self ( Or we can send it
in a header ).
3. Postpone the workflow integration with REST API to next release. ( We
will be still supporting workflows but REST API will not send workflow
related data )
I favor 3rd option since that will give us enough time to properly evaluate
the options and come up with a good design.
WDYT?
Thanks
Jo
On Thu, Nov 26, 2015 at 7:54 PM, Frank Leymann wrote:
> Dear all,
>
> why do we want to express by returning "ON_HOLD"? I assume (correct me if
> I am wrong) we want to say that the resource has not yet been created
> because the workflow is still running: it depends on the result of the
> workflow whether finally the subscription will be made or not.
>
> If this is the case, we must not return a "201 Created" because the
> resource is not created. But we have to return "201 Accepted" with a task
> resource in the body of the response; also, a Content-Location header has
> to be returned that contains the URL of the task resource; this URL will be
> used by the client to check changes in the status of the task (i.e. the
> workflow).
>
> If the long running request (the workflow) completed successfully, a GET
> on the URL of the task resource will return with "303 See Other" and a
> Location header field containing the URL of the created resource (i.e. the
> subscription).
>
> It the long running request completes UNsuccessfull, a GET on the URL of
> the task resource will return a "200 OK" BUT the task resource (i.e. the
> information about the status of the workflow) in the body will contain the
> information that the request failed together with other information we deem
> appropriate.
>
>
>
> Best regards,
> Frank
>
> 2015-11-24 14:21 GMT+01:00 Nuwan Dias :
>
>>
>>
>> On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe > > wrote:
>>
>>> Hi All,
>>>
>>> I configured the subscription creation workflow and tested it with the
>>> current implementation of the REST API.
>>>
>>> When we add a subscription in normal scenario we get the following
>>> response.
>>>
>>> *Request*:
>>>
>>> POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1
>>>
>>> {
>>> "tier": "Silver",
>>> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
>>> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
>>> }
>>>
>>>
>>> *Response:*
>>>
>>> HTTP/1.1 *201* Created
>>>
>>> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
>>> 63ab53d3-0cb7-46df-8ce9-cd84f2882b27
>>> Content-Type: application/json
>>>
>>>
>>> {
>>> "tier": "Silver",
>>> "subscriptionId": "63ab53d3-0cb7-46df-8ce9-cd84f2882b27",
>>> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
>>> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
>>> *"status": "UNBLOCKED"*
>>> }
>>>
>>>
>>> When we have a subscription creation workflow enabled, we receive a
>>> response like follow.
>>>
>>> HTTP/1.1 *201* Created
>>>
>>> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
>>> def79733-e55e-464f-9630-c1ae595344f2
>>> Content-Type: application/json
>>>
>>> {
>>>"subscriptionId": "def79733-e55e-464f-9630-c1ae595344f2",
>>>"apiId": "admin-pubApi-1.0",
>>>"tier": "Silver",
>>>"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
>>>*"status": "ON_HOLD"*
>>> }
>>>
>>>
>>> Here we can see that the status is ON_HOLD. In this case we can also see
>>> some more information that are coming from APIM underline implementation,
>>> which are follows:
>>>
>>>- redirectUrl : "http://google.lk";
>>>- displayUrl : "http://wso2.com";
>>>- workflowRefId : "0b94b11a-2736-48a0-b43e-c7cc35d8516d"
>>>- CallbackUrl : http://google.lk
>>>
>>>
>>> Do we need to include this info in the response object? If so what would
>>> be the best approach?
>>>
>>
>> What if we add this info to the response payload under a section called
>> something like "workflowInformation" ?
>>
>>>
>>> Few ways that are possible include:
>>>
>>>- Add those additional information into the response object
>>>- Add this redirect URL as HTTP 302 redirection as the Location
Re: [Dev] APIM REST API with Subscription Creation Workflows
On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe
wrote:
> Hi All,
>
> I configured the subscription creation workflow and tested it with the
> current implementation of the REST API.
>
> When we add a subscription in normal scenario we get the following
> response.
>
> *Request*:
>
> POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1
>
> {
> "tier": "Silver",
> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
> }
>
>
> *Response:*
>
> HTTP/1.1 *201* Created
>
> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
> 63ab53d3-0cb7-46df-8ce9-cd84f2882b27
> Content-Type: application/json
>
>
> {
> "tier": "Silver",
> "subscriptionId": "63ab53d3-0cb7-46df-8ce9-cd84f2882b27",
> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
> *"status": "UNBLOCKED"*
> }
>
>
> When we have a subscription creation workflow enabled, we receive a
> response like follow.
>
> HTTP/1.1 *201* Created
>
> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
> def79733-e55e-464f-9630-c1ae595344f2
> Content-Type: application/json
>
> {
>"subscriptionId": "def79733-e55e-464f-9630-c1ae595344f2",
>"apiId": "admin-pubApi-1.0",
>"tier": "Silver",
>"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
>*"status": "ON_HOLD"*
> }
>
>
> Here we can see that the status is ON_HOLD. In this case we can also see
> some more information that are coming from APIM underline implementation,
> which are follows:
>
>- redirectUrl : "http://google.lk";
>- displayUrl : "http://wso2.com";
>- workflowRefId : "0b94b11a-2736-48a0-b43e-c7cc35d8516d"
>- CallbackUrl : http://google.lk
>
>
> Do we need to include this info in the response object? If so what would
> be the best approach?
>
What if we add this info to the response payload under a section called
something like "workflowInformation" ?
>
> Few ways that are possible include:
>
>- Add those additional information into the response object
>- Add this redirect URL as HTTP 302 redirection as the Location header
>
> Please share your thoughts.
>
> Thank you,
> Malintha
>
> --
> Malintha Amarasinghe
> Software Engineer
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>
--
Nuwan Dias
Technical Lead - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] APIM REST API with Subscription Creation Workflows
Hi All,
I configured the subscription creation workflow and tested it with the
current implementation of the REST API.
When we add a subscription in normal scenario we get the following response.
*Request*:
POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1
{
"tier": "Silver",
"apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
}
*Response:*
HTTP/1.1 *201* Created
Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
63ab53d3-0cb7-46df-8ce9-cd84f2882b27
Content-Type: application/json
{
"tier": "Silver",
"subscriptionId": "63ab53d3-0cb7-46df-8ce9-cd84f2882b27",
"apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082",
"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
*"status": "UNBLOCKED"*
}
When we have a subscription creation workflow enabled, we receive a
response like follow.
HTTP/1.1 *201* Created
Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/
def79733-e55e-464f-9630-c1ae595344f2
Content-Type: application/json
{
"subscriptionId": "def79733-e55e-464f-9630-c1ae595344f2",
"apiId": "admin-pubApi-1.0",
"tier": "Silver",
"applicationId": "69041195-1e81-48f5-8892-2ab053b0501c",
*"status": "ON_HOLD"*
}
Here we can see that the status is ON_HOLD. In this case we can also see
some more information that are coming from APIM underline implementation,
which are follows:
- redirectUrl : "http://google.lk";
- displayUrl : "http://wso2.com";
- workflowRefId : "0b94b11a-2736-48a0-b43e-c7cc35d8516d"
- CallbackUrl : http://google.lk
Do we need to include this info in the response object? If so what would be
the best approach?
Few ways that are possible include:
- Add those additional information into the response object
- Add this redirect URL as HTTP 302 redirection as the Location header
Please share your thoughts.
Thank you,
Malintha
--
Malintha Amarasinghe
Software Engineer
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/
Mobile : +94 712383306
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
