@furystack/rest 8.0.18 → 8.0.20

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +9 -9
  2. package/package.json +5 -5
package/README.md CHANGED
@@ -1,17 +1,17 @@
1
1
  # REST
2
2
 
3
- REST API Model package for FuryStack
3
+ REST API model package for FuryStack.
4
4
 
5
- ## Generic concept
5
+ ## Generic Concept
6
6
 
7
- An ideal way to implement REST APIs in FuryStack is the following:
7
+ An ideal way to implement REST APIs in FuryStack is as follows:
8
8
 
9
- 1. Design the REST API - Create an interface that defines all endpoints, all requirements and all possible return values (~_this package_) You can place in a common module in a Monorepo that can be accessed both with the Backend and Frontend logic to share the API definition
10
- 1. Implement the defined API endpoint using the interface on the backend service (~@furystack/rest-service)
11
- 1. Import the predefined interface and use it on the client (@furystack/rest-client-fetch package)
12
- 1. Be happy. Type safety can protect your ass if you do breaking changes with your REST API
9
+ 1. Design the REST API Create an interface that defines all endpoints, requirements, and possible return values (this package). You can place it in a common module in a monorepo that can be accessed by both backend and frontend logic to share the API definition.
10
+ 2. Implement the defined API endpoint using the interface on the backend service (see @furystack/rest-service).
11
+ 3. Import the predefined interface and use it on the client (see @furystack/rest-client-fetch package).
12
+ 4. Be happy. Type safety will protect you from breaking changes in your REST API.
13
13
 
14
14
  ## Disclaimer
15
15
 
16
- 1. Your service and client will be tightly coupled. However it can be beneficial if this is intentional but it doesn't fin in all REST API scenarios
17
- 1. Validation doesn't come with type definitions by default - Type safety is compile-time only
16
+ 1. Your service and client will be tightly coupled. This can be beneficial if intentional, but it doesn't fit all REST API scenarios.
17
+ 2. Validation doesn't come with type definitions by default type safety is compile-time only
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@furystack/rest",
3
- "version": "8.0.18",
3
+ "version": "8.0.20",
4
4
  "description": "Generic REST package",
5
5
  "type": "module",
6
6
  "scripts": {
@@ -37,13 +37,13 @@
37
37
  },
38
38
  "homepage": "https://github.com/furystack/furystack",
39
39
  "dependencies": {
40
- "@furystack/core": "^15.0.18",
41
- "@furystack/inject": "^12.0.15"
40
+ "@furystack/core": "^15.0.20",
41
+ "@furystack/inject": "^12.0.17"
42
42
  },
43
43
  "devDependencies": {
44
- "@types/node": "^22.15.17",
44
+ "@types/node": "^24.0.1",
45
45
  "typescript": "^5.8.3",
46
- "vitest": "^3.1.3"
46
+ "vitest": "^3.2.3"
47
47
  },
48
48
  "gitHead": "1045d854bfd8c475b7035471d130d401417a2321"
49
49
  }