I'm building a business application to manage inventory requisitions. The application is a lightweight web interface used mainly by our internal employees to submit inventory requisitions. The requisitions will pass through a workflow of activities, mainly for validation and approval, and finally, an IC Internal Usage entry should be created in Sage by the application before the requestor can receive the items.
Surprisingly, the Sage web API provides endpoints to create and retrieve almost all types of IC transactions except Internal Usage. I can't understand the rationale behind that, yet I'm looking for a way to create (and post) Internal Usage entries externally from my application, and I'm not aware of any solution for this.
Related
I use two independent eCommerce platforms that don't officially support communication with one another, however, both have exposed REST API for managing products, orders, etc.
My question is: how can I leverage their APIs to allow the two platforms to exchange data?
Neither platform offers a workspace to code API calls and execute on retrieved records, so I don't understand how this scenario fits in the client server model.
Would this require a third node to be set up to act as the client with each of the eCommerce platforms acting as servers?
If so, then I surmise that this client would need to, for example, perform a GET request from Platform A, store the retrieved records in a database, then perform a POST to create the records in Platform B.
If my above understanding is correct, can anyone please advise on a platform/service with which this functionality can be built and managed? Is Postman what I'm looking for?
I'm still new to web API development, so please excuse my ignorance.
Any help would be much appreciated.
Thanks
Use case
I am building a webshop where people can register/sign in and can purchase (and afterwards manage) their SaaS licenses. For this purpose I created (among others) the following REST endpoints:
// Lists all licenses which are linked to this user
r.Get("/users/{userID}/licenses", api.LicenseSvc.HandleGetLicenses())
// List details (such as purchase date, seat information, ...) for a given licenseID
r.Get("/users/{userID}/licenses/{licenseID}", api.LicenseSvc.HandleGetLicense())
// Creates a new license for the signed in user
r.Post("/users/{userID}/licenses", api.LicenseSvc.HandleCreateLicense())
// Each license has a limited number of seats. The license manager can free up seats to make room for others
r.Delete("/users/{userID}/licenses/{licenseID}/seats/{seatID}", api.LicenseSvc.HandleDeleteSeat())
The above endpoints are only supposed to be used in the webshop/license management panel. At the same time the same service has to serve endpoints for the SaaS products which actually use the license(s) a user has created/purchased before. This SaaS product needs different endpoints such as:
An endpoint to check at startup whether a given license is valid at all
An endpoint which also gets the license by ID (see above), but it should only return a subset of the license resource (e. g. it shouldn't return the date when the license was purchased)
My question
Due to the fact that I am building one REST API which is consumed by two different "audiences" (on the one hand the license manager/customer and on the other hand the SaaS software) I feel like I am running into conflicts.
The authentication of both audiences is different, both audiences want to access the same kind of resource (e. g. a license) but the resource "format" (no customer sensitive data for the SaaS requester) should be different depending on the audience.
Should this be reflected via different REST URLs or should I handle all that logic inside of my route handlers?
Should I even create two different services serving these different audiences? Like one API for the userpanel/license management and one for the SaaS products!?
REST is not very well prepared for these multi-client scenarios. i have seen many REST apis where certain attributes of resources will only be filled under certain circumstances where i find that perfectly fine. however i have also seen many examples of multiple use cases bunched into single resource models where the swagger documentation with its limiting structure terribly fails to communicate the purpose of each field.
so: as long as the use cases do not differ too much, i would try to keep the count of endpoints low.
tip: have a look at GraphQL, it is much better equipped for handling such cases with querying only for certain sets or even only asking for certain fields, putting the client in control. however using GraphQL as the primary interface is still somewhat exotic and comes with quite substantial initial cost compared to the plentiful REST infrastructure available. still worth it.
We are currently using direct DB connection to query mongodb from our scripts and retrieve the required data.
Is it advisable / best practice to make the data retrieval from DB as a microservice.
It does until it doesn't :)
A service needs to get its data from somewhere and a database is a good start. If you have high loads you may find that you need to add a cache in the middle see this post from Instagram engineering https://instagram-engineering.com/thundering-herds-promises-82191c8af57d
edit (after comment)
generally speaking, a service should own its database and other services shouldn't access another database service directly only via its API. The idea is to keep services autonomous and enable them to evolve independently.
Depending on the size of microservice, that's now always practical since it can make the overhead of having the service be more of the utility it provide (I call this nanoservices). Also, if you have a lot of services you don't want to allow each one to talk to any other (even not via the DB) since you just get a huge mess. The way I see it there should be clear logical boundaries (services or microservices) and then within each such logical services you may find that it makes sense to have more than one "parts" (which I call aspects) e.g. they have different scaling needs or different suitable technologies etc. When you set things this way aspects can access the same database and services shouldn't (and you can still tame the chaos :) )
One last thing to think about - who said API is only a REST API, you can add views on top of the data that belongs to another service and as long as you treat that like an API (security, versioning etc.) you can have other services access that as well
We are using Integration Manager to create a batch of monthly invoices. I want to build a replacement that creates a batch in GP and imports the invoices into the batch. After review, the batch will be posted to GP. Is this doable with either of these API's and which would you choose?
Integration manager can use econnect for its insertion engine. If you are processing a high volume of transactions, you will notice a huge difference between integration manager's UI engine and econnect. When you create a new integration, simply choose the econnect option and whatever data source you have set up.
Concerning the non-IM APIs, both may be used, and they are situational. The web services sits on top of econnect, and it is much slower integrating because you are passing information between several layers. It does provide a secure link between your SQL server and any outside integration sources, and it is ideal if you need to setup something to allow integrations to happen through middleware such as a billing gateway. If you have access to build an econnect process/app that makes a connection to your SQL server for GP, this is the fastest way to integrate SOP and receivable transactions. It maintains all the business rules to help ensure GP does not break in as a result of a patch, and the speed is fast enough to push thousands of records without requiring a custom integration solution.
If you want to get done quickly, and do not mind working from the integration manager interface, just build your integrations using econnect. If you have the time to develop a custom integration routine, go for econnect. If you want to leverage WCF technology on top of econnect, go for web services.
Each are listed in the amount of time it will take you to develop from fast implementation to slower implementation.
I'm looking for some guidance on my research to building an SaaS. This thread seems to be related, but I'm wondering if this software Rackspace has called rBuilder is what I would be looking for to automate the process of creating an instance of the software with a unique IP address and domain name.
Also, for an application similar to Shopify, does the application work like Facebook where it serves up different information based on the account, or is it better to have separate installs of the software like WordPress, but on a server that you maintain?
IMHO, there are various levels of Multi-tenancy [level1 through level4], among them, the purest form of multi-tenancy [Level4] is to have a single code base to cater to the needs of different customers [tenant's].
In this case, you will be required to maintain all of the configuration metadata within your code base to ensure that each tenant has the capability to customize the application the way they wanted to.
Having a single codebase is very clean, easier to maintain, easy to patch, easy to onboard new customers etc...
Hence, kindly note that you have to decide on the time and expense that you have budgeted for the application that you have planned to as the purest form of multi-tenancy does require some more additional thought process.
You can consult some articles like this and also google on the pros and con's of having the purest form of multi-tenancy vs on-premise model or virtualized model of multi-tenancy.
Also read more from here