Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hello! I'm looking to implement an API that has URL scheme like the following: ```/partnerName/order

U01DE320SN6
U01DE320SN6 Posts: 37 🧑🏻‍🚀 - Cadet

Hello! I'm looking to implement an API that has URL scheme like the following:

/partnerName/orders
/partnerName/skus
...

As far as I get it from reading the existing Glue code, it looks like first level is always reserved for some REST entity, so only the following is possible:

/partner-export-orders
/partner-export-orders/1/return

Am I right that placing everything under the root partner domain is not possible in glue? And what should I do in this case? My partner also requires some custom authorization which is not oAuth protocol, and response format which is regular JSON arrays without REST wrappers, so maybe it's better for me to consider Yves as the platform instead?

Comments

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,004 ⚖️ - Guardians (admin)

    Heyhey,
    first of all: most is possible - because in the end it is just php 🙂

    Glue is meant to be a restful api which means that the urls should always follow the same structure and logic for the data you are handling. If you would implement it like your first example you would break this in my opinion.

    Nevertheless: if it is a hard requirement to have it like that then you can change it. For that have a look in https://github.com/spryker-shop/b2b-demo-shop/blob/202212.0-p2/src/Pyz/Glue/Router/RouterDependencyProvider.php#L21 and maybe create your own router plugin and make it the first in the list.

    If something like /partner-export-orders/ would work for you, then i would propose this.

    Please also have in mind: are these endpoints for customers or for another system? - if the latter then please have a look into glue backend api docs

  • U01DE320SN6
    U01DE320SN6 Posts: 37 🧑🏻‍🚀 - Cadet

    Yes, it's for another partner system.
    Okay, this makes me a little confused. Am I correct that currently Spryker has two different Glue instances, one of which is customer API, and another is the api for users?

    Also, what is backend_api_eu application I see now in the new b2c suite files?

    backend_api_eu:
                    application: zed
                    endpoints:
                        backend-api.de.spryker.local:
                            store: DE
                            entry-point: BackendApi
                        backend-api.at.spryker.local:
                            store: AT
                            entry-point: BackendApi
    
  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,004 ⚖️ - Guardians (admin)

    Yes, our newly upgraded Glue API is not only for usable for customers but is now officially prepared to be used for administrational requests as well (ala Back Office actions).
    So everything what was Glue API before will be glue-storefront in the future. Sprykers previously never-out-of-beta backend-api got replaced with Glue backend API.

    So afaik the backend-api was used for that beta Spryker Backend API (or also known as Zed API) which just wa sin beta state and now is not continued anymore.

  • U01DE320SN6
    U01DE320SN6 Posts: 37 🧑🏻‍🚀 - Cadet

    Okay, that clarifies things a little bit. And still, for integrations like PayOne I see that you guys handle requests via Yves as the API gateway, and not Glue. Am I right that for signature-based authorization (our partner can't use oAuth for technical limitations of their platform) is the best way to handle things? Or you'd rather suggest to go with Glue with public endpoints and custom authorization provider?

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,004 ⚖️ - Guardians (admin)

    With the Payment service provider integrations it is a problem: They were build over time with the services/endpoints which were available at that time…

    In an ideal world these PSPs should use Glue Backend API to do the payment authorisation hooks. So either Glue Storefront API or Yves for the customer-facing interactions with the PSP and glue backend API for calls from the PSP to Spryker.

    Currently it is used quite differently by different PSP integrations. Also the new Glue Storefront/Backend separation is very new and not even introduced in the standard demoshops yet. But hopefully will come in the next release.