I’m learning about micro services and API gateways. Some articles mention that api gateways only have one endpoint. Is that correct?
Let’s say my e-commerce page makes 2 calls, /products and /users to get products and user data, and they are in a Product service and User service respectively.
Does my client make calls to api.com/products and api.com/users separately? Or does it do api.com/exec?endpoint=users (or something like this)?
From the context, it seems that the endpoint here is the domain - api.com. The specific url inside that domain, this is something for api gateway owners to decide on.
Typically there are two different approaches to api. In your example, there are two services and one way of exposing them to customers would be:
products.api.yourcompany.com
users.api.yourcompany.com
Clearly, each service would own its own endpoint (domain) and they can use any url format for specific operations; like /operationAbc or exec?operation=abc etc.
The second approach, and this is were api gateways shine, both services can be hidden behind single endpoint: api.yourcompany.com - and the api gateway decides how actual operation call looks like.
Related
I have a backend service which is to provide an endpoint to access book reviews. If I have to create an endpoint which returns all reviews for a given book, I can think of two ways to structure the URL path:
{url}/books/{book_id}/reviews
OR
{url}/reviews/{book_id}
Is one preferred over the other? Are there established standards? Or should both exist?
When talking about a service layer, I might talk about adding an Endpoint to a service. ...but when I want to talk about the corresponding consumer of that specific endpoint I would want to talk about the Client's "Invoker"?
Feels like there should be a term for this and it's been bugging me for days.
Are you maybe thinking of an API call? Like what a user uses to get access to the endpoint?
I had a question regarding global availability of an API and performance. Basically, we would like to build an API that is central to our business, but it must be highly available and performant globally, meaning, response times of the API should be minimal whether the call is being made in the United States, China, or any other country in the world. The API is actually an interface into a microservice architecture that is domain driven. We are currently using Microsoft Azure as our cloud provider to host these microservices but I wanted to get some suggestions on architecting a solution that makes this performant across the globe. Would we need to deploy services in multiple regions to be able to make this work? If so, how would I route an incoming request to the appropriate region?
I would partition your data by region using username as the partition key. Distribute your microservices and databases around the world in appropriate places, but keep one central login service. As users register with your central registration service, you assign them to a region depending on their home address, IP, or some other geographical indicator. When they return to login the second time (using the central service), you authenticate them and pull their region from the central DB. You can now route all additional traffic to the proper region for the best performance.
You would have to implement a full set of domains in each region.
I want to make a desktop application which will need to use a 3rd party REST API to get information. However, the number of requests is limited by the API Key. If I use one API key for all users, the request quota will be exhausted really fast. Now, is it standard (and legal) to make each user sign up for his/her own API key? How are API keys used in context of open-source projects?
To generate the API key, I want to make a sign up form within the application, where the user puts in his/her information and the application sends those information to the 3rd party website to get an API key. Does that sound right?
In general the use of an API is limited to the requests from one machine and not to the API key most of the time.
Again depending of the type of third party services you are using, but the requests to the service should be established by the client not the server.
For example if you want to know geographic coordinates from a specific place, but obviously you can't ask the user directly for GPS coordinates. So you implement the Google Maps Javascript Library into your app which requests the Google API for the coordinates to the human readable address and returns it to the client. This in turn sends the data to your server.
In this way your server never comes into contact with the third party service.
If you have sensitive data or data which shouldn't be manipulated by the user you have to request from your server directly of course. But take a look into the documentation of the service before hack something together which isn't in the intention of the service provider.
Never ever try to outwit a service provider. They will detect your inappropriate use and block you for all time!
Help me clarify terminology regarding the HTTP API.
Gateway URL and endpoints are the same thing, correct?
This is just the place to make a GET or POST call, correct?
Now for my question. It seams for each of the eBay API has its own gateway.
The Shopping API gate way is http://open.api.ebay.com/shopping?
I'm assuming the fallowing:
Finding: http://open.api.ebay.com/finding?
merchandising: http://open.api.ebay.com/merchandising?
... and so on.
Is this correct? or am I misunderstanding something.
Yes, the end point is the gateway. Each API has its own endpoint/gateway url. You would think that eBay would name their endpoints with the schema you provided, but they didn't. You will need to click on "Making a Call" after selecting the API you want the endpoint for in the documentation.
Example:
Here is the endpoint documentation for the Trading API, Shopping API, and Finding API.
Also you should know that not every endpoint is going to require the same info. For the trading API you are going to need a Token from the seller as well as your APP ID, whereas the shopping and trading API only needs the APP ID.