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

U01DE320SN6

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?

fsmeier

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

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

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

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

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.