Rationale

Let's say you want to build an online marketplace. You will need the inventory management system, product catalog, shopping cart, order management system, payment, invoicing, shipping, product reviews, and many other modules. It is tempting to design a unified database that keeps track of everything and build a monolithic app on top. It will likely become a monumental effort. A better approach would be to build the individual modules in the order of their priority.

Use Code On Time to put together an inventory management system. The built-in rich user interface will likely satisfy your needs at least in the beginning. Touch-friendly UI and the ability to run the apps in the native mode (PWA) out of the box will save a tremendous amount of time and money. The built-in RESTful API Engine automatically mirrors the user interface capabilities and is ready to be enabled to serve as the backend of the custom mobile and web applications whenever the moment arrives.

As soon as the MVP (minimal viable product) of the inventory management system is ready, have it deployed.

Create a separate database to keep track of users and roles. Put together a Marketplace Identity application on top of the database with Code On Time. The built-in security system supports the 2-Factor Authentication and optional integration with the external identity providers, such as Google, Microsoft, or Facebook. Deploy the Marketplace Identity application to the server.

Sign into the inventory management system as administrator and configure the Marketplace Identity app as its Cloud Identity Provider. From now on, users signing into the inventory management system will be redirected to confirm their identity with the Marketplace Identity application.

Suppose that the next target is the order management system. Build it to make sure that you can convert the contents of the future shopping cart into a bona fide order. You can add the required tables to the same database schema. Alternatively, set up an entirely new database and make sure that its references to the product inventory are sufficient to keep track of the order-specific information such as SKU, brand, name, and price. The order history becomes isolated from the accidental changes to the product price that would affect the historical orders. Add the membership support to the dedicated database of the order management system.

Sign into the order management system as administrator and configure the Marketplace Identity app as its Cloud Identity Provider.

Continue to build the other modules of the online marketplace. Make them independent and provide each with its own database and membership. Use Code On Time to create the data management screens automatically mirrored in the custom RESTful API of the module. Configure the Marketplace Identity for user authentication.

Use the best-of-the breed frontend libraries and frameworks to put together the product catalog and the shopping cart modules. The RESTful APIs of the modules are authenticated with the access tokens issued by the Marketplace Identity application. Your custom apps will use the OAuth 2.0 protocol to authenticate the users and obtain the tokens.

You will be able to create a cosmos of powerful microservices complete with their RESTful APIs and sophisticated user interfaces for data management. Each microservice is the module that can be evolved and continuously deployed independently.

Custom mobile and web applications will rely on the microservices for their backend functionality. JavaScript-based clients can reference the restful.js script of the identity provider application. The script provides the lightweight wrapper $app.restful on top of the Fetch API. The in parameter in the method argument can specify the name of the module that will respond to the API request.

Only Code On Time makes it possible for a single-man shop or small team of developers to put together applications that rival the software produced by the industry giants! Perfect for prototyping and everyday production use.

Individual microservices can be replaced over time with the custom implementations eliminating any possibility of a technological lock-in.

Labels: Microservices, RESTful

Monday, May 2, 2022Print Subscribe

Lesson: ETag and HTTP Caching

RESTful API Engine responses are provided with the ETag header. Browsers automatically submit ETag with the subsequent requests to fetch the same resource. The engine responds with the HTTP status 304 and empty body if the ETag of the resource has not changed. Apps can also submit ETag with CRUD requests for conflict detection.

Detect the data editing conflicts and build high performance applications by taking advantage of the HTTP protocol.

The *ETag* of the resource specified in the *If-Match* header of the PATCH request allows detecting the data editing conflicts.

The items of the *Supplier Company Name* and *CategoryName* lookups are fetched from the RESTful Application with GET requests. The physical data transfer happens one time only for each lookup for each subsequent opening of the *Edit Product* form.

Firefox Developer Tools provide a complete list of HTTP requests executed by the web application. Other browsers may not provide the full picture of the network traffic between the client and the server. — The RESTful Application responds to the lookup requests with the HTTP status code 304. It tells the client that the *ETag* of the corresponding resource is unchanged and the previously fetched copy of the response can be used instead.

This tutorial is part of the RESTful Workshop designed to empower individual developers and teams to create amazing enterprise-quality backends for mobile and web applications. Zero experience and no code is required to provide your data with the REST API conforming to the Level 3 of Richardson Maturity Model with the built-in OAuth 2.0 and Open ID Connect.

Labels: Caching, Conflict Detection, RESTful

Thursday, April 21, 2022Print Subscribe

Lesson: BLOBs with RESTful API

Values of Binary Large Objects (BLOBs) are represented as resource URLs in the data. User identity must be specified in the Authorization header to get or change a BLOB. Hypermedia links to replace or delete BLOB values are included. Developers submit binary data as fields in the body property of the $app.restful method argument or as the named values in the multipart/form-data of HTTP requests.

Work with the BLOB resources like a pro.

RESTful API Engine identifies the user automatically when the host application is making a request. The cookie with the self-encrypted user access token provides the identity information.

Postman shows the BLOB fetched from the resource with the authorization key specified in the "x-api-key" query parameter. RESTful API Engine requires an access token or authorization key to be specified explicitly by the external applications.

The standalone single page application fetches the image of the product category on-demand when the category name is clicked. The app follows the hypermedia links to find the product category "picture" field value.

Labels: BLOB, REST, RESTful, RESTful Workshop

RESTful

Learn how to make your apps faster with ETag and Caching. Use the ETag header to detect conflicts.

Rationale