# ngx-restangular: a REST client service for Angular > ngx-restangular is the maintained successor to Restangular, an Angular service that turns a RESTful API into a fluent object model where every element and collection comes back with the HTTP verbs attached. Version 7 rebuilt it in the partial Ivy format so it works with Angular 16 through 22 without the ngcc shim that broke the older lines. **2muchcoffeecom/ngx-restangular** — Restangular for Angular 2 and higher versions - Repository: https://github.com/2muchcoffeecom/ngx-restangular - Website: https://2muchcoffee.com/ngxrestangular-app-development - Stars: 773 · Forks: 108 - Language: TypeScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/2muchcoffeecom-ngx-restangular ## The Restangular idea, carried into modern Angular ngx-restangular is an Angular service that simplifies common GET, POST, DELETE, and UPDATE requests with a minimum of client code, and it is described as a fit for any web application that consumes data from a RESTful API. The project is the follow-up of Restangular, and the README says that almost all of the functionality was transferred from it. That lineage explains the API shape, which is unusual compared with the Angular HttpClient. Rather than returning an HttpResponse and leaving you to build URLs and shapes, the service returns a restangularized object: a collection gains methods like get, post, put, and remove, and an individual element gains its own methods, so the code reads as a sequence of calls on the thing you are working with rather than a sequence of URL constructions. The vocabulary in the documentation is consistent about this. There is a distinction between Restangular methods, element methods, and collection methods, and then custom methods, which you can add to a collection or to a model. There is a whole section on copying elements, on using values directly in templates with observables, and on URL building. The project is MIT licensed, written in TypeScript, and maintained by 2muchcoffee, whose site carries a page on the library and a blog post on using it for a RESTful API Angular solution. The repository holds the library under projects, a small demo application under demo, configuration under config, and a tools directory that contains a script worth returning to later. The demo is the fastest way to see the whole thing working, and the README explains how to run it: the demo folder is a small app that uses the library, you run npm run build and then npm start. ## Installing it, and the dependency change in 7.0.0 The installation is a single package. ```bash npm install ngx-restangular ``` Two details follow. The lodash-es and tslib packages install with it, so you do not add them yourself. And since 7.0.0 the package does not need core-js or lodash from your app, so if you only had them for ngx-restangular you can remove them. That last sentence is the kind of note that saves an afternoon, because a leftover polyfill dependency in an application is the sort of thing that survives a migration and then confuses a later bundle size conversation. The dependency list shrinking at the same time as the format changed is a reasonable bet, since the partial Ivy build is compiled by the consuming application rather than shipped pre-linked. There is also a naming history to be aware of, because old tutorials and old lockfiles use the old name. The project was renamed from ng2-restangular to ngx-restangular due to the implementation of semantic versioning by the Angular Core Team, and the npm name changed with it, so you install the actual version of the project with npm install ngx-restangular. The old name, ng2-restangular, appears in the compatibility table as the line for Angular 2. The package metadata also records the author as logvinoleg89, and the keywords list still carries the full history of the name and the Angular versions it has served, from angular2-restangular through angular10-restangular, which is a small illustration of how long this package has been carried forward. ## The compatibility table, and what ngcc did to the old lines The compatibility table is the most practical thing in the README, because this library has been carried across a decade of Angular versions and the answer to which line to use is not obvious from the version number alone. The 7.x line supports Angular 16 to 22 with RxJS 7.4 or later. The 6.x line is for Angular 10 with RxJS 6, 5.x is for Angular 8, 4.x for Angular 7, 3.x for Angular 6, 2.x for Angular 5 with RxJS 5, the 1.0.13 release for Angular 4, and the original ng2-restangular for Angular 2. The reason the old lines stopped working is worth understanding, because it is a packaging story rather than a feature story. 6.x and older were published in the View Engine format, and Ivy applications could only use them after ngcc converted the package, which is where errors like the missing ɵmod property on the RestangularModule came from. Angular 16 removed ngcc, so 6.x cannot be used on a modern Angular, and the 7.x line is the way forward. How 7.0.0 is built is stated with the same specificity. It is built with Angular 21 in the partial-Ivy format, the format Angular recommends for libraries on npm, so your application's own compiler links it. And the testing claim behind it is unusually concrete. Every Angular major from 16 to 22 was checked by installing the packed library into a fresh application, running a production build, and sending requests through it, and the tools directory holds a check-consumer.sh script that repeats that check for any version. That is a much stronger statement than a compatibility table on its own, because it describes a test that exercises the actual consumer path rather than a matrix someone wrote down. ## Twenty setters, and a configuration you can scope The configuration surface is the part of the API that people underestimate, and the table of contents lists it in full: withConfig, setBaseUrl, setExtraFields, setParentless, addElementTransformer, setTransformOnlyServerElements, setOnElemRestangularized, addResponseInterceptor, addFullRequestInterceptor, addErrorInterceptor, setRestangularFields, setMethodOverriders, setDefaultRequestParams, setFullResponse, setDefaultHeaders, setRequestSuffix, setUseCannonicalId, setPlainByDefault, and setEncodeIds. The names are compact but the grouping is clear. Some set the shape of the data, such as setBaseUrl, setExtraFields, setParentless, and setRestangularFields. Some control the interceptors, with separate hooks for responses, full requests, and errors. Some adjust the HTTP layer, with setDefaultRequestParams, setFullResponse, setDefaultHeaders, setRequestSuffix, and setEncodeIds. And a few change the identifier handling, setUseCannonicalId and setPlainByDefault, which tie back to the FAQ cases below. The important structural point is that the configuration is not global-only. The documentation covers accessing the configuration, configuring it globally in the AppModule, configuring it in the AppModule with dependency injection applied, creating a Restangular service with a different configuration from the global one, and a decoupled Restangular service. That last capability is the one that decides whether the library fits a large application. A single global base URL and a single set of interceptors is fine for a small app and wrong for an app that talks to several backends with different authentication, and a decoupled service per API is the answer. The base configuration and the per-service configuration are separate concerns, and the documentation treats them as separate sections, which is a sign that the library was designed for the multi-backend case rather than retrofitted onto it. ## Element and collection methods, and the restangularization model The method taxonomy is the heart of the library, and the table of contents splits it three ways. Restangular methods are the ones on the service itself, which is what you use to reach a collection in the first place. Element methods are the ones you get on a single returned object, which typically means get, save or put, and remove, and they act on that element's own URL. Collection methods are the ones on a collection, which typically means post to add something, and get or remove to act on the collection as a whole. Custom methods are the fourth category, and there are separate sections for adding them to collections and adding them to models, each with an example. That is a genuine feature rather than a convenience, because it means the API surface can be expressed in the vocabulary of your domain, with a method that reads like part of your application rather than part of a generic HTTP client. The restangularization model is what ties the elements together. The FAQ entries show the edge cases that a user actually hits. How do I handle CRUD operations in a list returned by Restangular. How do I remove an element from a collection while keeping the collection restangularized. And how can I access the unrestangularized element as well as the restangularized one. The last of those three is the one that tells you the design philosophy. The library keeps both forms available, the plain object and the one with the methods attached, and the transformation is done by an element transformer. setTransformOnlyServerElements and setOnElemRestangularized are the settings that control that transformation, which tells you that whether an object gets wrapped is configurable rather than assumed. For the data flow itself, the documentation covers both idioms. There is a section on working with observables, and one on using promises, and a section on using values directly in templates with observables, which is the part that matters for an Angular application, since the async pipe expects an observable and a library that returns the wrong thing there is a constant source of friction. ## The FAQ is where the practical knowledge lives The FAQ is long, and its length is a good sign, because each entry is a case where the default behaviour does not match the situation the reader is in. Error handling has its own entry, and the interceptor settings are the mechanism behind it. Three entries are about requests that need something added to every call. I need to send an Authorization token in every Restangular request. I need to send one header in every Restangular request. And how can I add withCredentials params to requests. The first two are what setDefaultHeaders and the interceptor settings are for, and the third is the option that lets a browser send cookies and credentials cross origin, which is a requirement for cookie-based authentication and a configuration decision with security implications rather than a default. Three entries are about identifiers, and they are the ones that trip people up. How can I send a delete without a body. The Mongo case, where the id of the elements is _id and not id as the default, so requests are sent to undefined routes. And the case where each model has a different id name, such as CustomerID for Customer. The Mongo one is the classic. A library that assumes the identifier is called id will build a URL containing undefined for a document whose key is _id, and the failure looks like a routing problem rather than a configuration one. The per-model id name case is the same problem in a harder form, and it is what setRestangularFields and the canonical id setting exist for. Two more entries are about files and about lists. How can I send files in my request using Restangular, and how do I handle CRUD operations in a list returned by Restangular. And the repository has a section on server frameworks, which is a pointer to the kinds of backends the library is used against. The last thing worth noting is the build and test setup, which is small and modern. The scripts are ng for the CLI, start to serve the demo application, build to build the library and copy the README and the LICENSE into the distribution directory, build:demo for the demo, and test running the Angular test target with the watch flag off. The development dependencies are on Angular 21, with the build and CLI packages at 21.2 series and the common package at 21.2.0. ## Conclusion ngx-restangular fits an Angular team that already knows Restangular, or that wants a single injectable service that gives every API collection the same set of verbs and lets a model carry its own extra methods, and that is on Angular 16 or later. It does not fit a new project that would rather use the HttpClient directly, since the value here is the object model rather than the transport, and it does not fit an application still on Angular 10 or earlier, where the compatibility table points at a line that predates the Ivy rewrite. Verify first that you are on Angular 16 to 22 with RxJS 7.4 or later, that you have removed core-js and lodash from your own dependencies if you only had them for this library, and that the identifiers your API uses match the ones the library expects, since the Mongo id case in the FAQ is the common surprise. ## FAQ ### How do I install ngx-restangular? With npm install ngx-restangular. The lodash-es and tslib packages install with it, and since 7.0.0 the package no longer needs core-js or lodash from your own application, so you can remove them if you only had them for this library. ### Which Angular versions does ngx-restangular support? The 7.x line supports Angular 16 to 22 with RxJS 7.4 or later, and it is built with Angular 21 in the partial-Ivy format. Older lines are 6.x for Angular 10, 5.x for Angular 8, 4.x for Angular 7, 3.x for Angular 6, 2.x for Angular 5, 1.0.13 for Angular 4, and ng2-restangular for Angular 2. ### Why does ngx-restangular 6.x not work on modern Angular? The 6.x and older releases were published in the View Engine format, and Ivy applications could only use them after ngcc converted the package, which produced errors like the missing ɵmod property on the RestangularModule. Angular 16 removed ngcc, so those versions cannot be used on a current Angular. ### How do I send an Authorization token on every ngx-restangular request? The configuration surface includes setDefaultHeaders and separate interceptor hooks for responses, full requests, and errors, and the FAQ covers both the Authorization token case and the case of a single header on every request. The same set of settings also covers adding withCredentials to requests. ### How do I handle a Mongo-style _id with ngx-restangular? The default identifier is id, so a document whose key is _id will produce requests to undefined routes. The configuration has settings for the fields Restangular uses, including setRestangularFields and the canonical id setting, and the FAQ also covers the case where every model uses a different identifier name, such as CustomerID for Customer. ## Sources - [2muchcoffeecom/ngx-restangular on GitHub](https://github.com/2muchcoffeecom/ngx-restangular) - [Issues](https://github.com/2muchcoffeecom/ngx-restangular/issues) - [License: MIT](https://github.com/2muchcoffeecom/ngx-restangular/blob/master/LICENSE) - [Project website](https://2muchcoffee.com/ngxrestangular-app-development) - [README](https://github.com/2muchcoffeecom/ngx-restangular/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/2muchcoffeecom-ngx-restangular