-
Notifications
You must be signed in to change notification settings - Fork 37
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
Additional orchestration capabilities would be useful #405
Comments
I had thought about an
The api should support the following cases
Would this idea also be possible / useful? |
Well yes this looks promising. The pros are that in case of complex orchestration use cases, such API would allow to implement basically anything. But this idea is definitely worth consideration as it will bring endless possibilities to httpyac and will lift it to another level. |
I once created a first implementation for the api. I'm not documenting this properly on httpyac.github.io yet, but just want some feedback.
I am not sure if your design is more understandable. But yes, we will probably lose some QA staff. However, the complexity in implementation is considerably less and you gain much more possibilities with the API. |
I tried that out and.. well it just works :)
So this is something to think about, but what you already implemented is really cool. This api brings totally new and awesome possibilities to httpyac. Thanks! |
I understand your desire, but I'm not comfortable with the change. For one thing, you are still missing the specification of |
@woolfas I have released a version with async support. Now it should also be possible similar to your example. You need to add await Statements |
Thank you for this improvement. That's great! I tested it and it works. But I also found the issue.
If you will execute
|
That the variables are available in the global context not only in the templates but also in the javascript is simply because I was too lazy to distinguish between them. It would be possible to put the variables back to the global context, but it doesn't feel right. I implement the |
Perfect! That solves the issue. Thanks |
Consider the use case where I want to invoke (or skip) a request based on the previous request response. Take a look in this http example which illustrates that:
In the "Shopping Use Case #1" I want to buy the Orange and Cake if I got "fruit" in the previous request. I made the ugly workaround using the
loop
for that, but I think it would make more sense having theif
condition which is missing right now in HttpYac.In this case the code would look nicer:
But if I would like to buy the Cake regardless if I bought Orange or not, then "Shopping Use Case #1" has a problem and it is illustrated in the "Shopping Use Case #2". In this case
isMilk
isfalse
, therefor the execution stops at theloop
line and bothbuy_item
requests are not executed at all.To fix that issue I suggest to introduce
loop
andif
blocks. e.g.That will give additional request orchestration possibilities and also will allow to execute multiple requests in the scope of a block.
So if we had that in HttpYac, the previous code could be improved something like this:
So in summary I suggest to introduce two improvements:
@if
annotation@loop - @endloop
and@if - @endif
blocksPlease consider implementing these improvements
The text was updated successfully, but these errors were encountered: