account-json-api - npm Package Compare versions

Comparing version 1.0.2 to 2.0.0

package.json

@@ -6,4 +6,5 @@ {
   "scripts": {
-    "test": "exit 0",
-    "semantic-release": "semantic-release pre && npm publish && semantic-release post"
+    "test": "npm run -s summary",
+    "semantic-release": "semantic-release pre && npm publish && semantic-release post",
+    "summary": "scripts/summary.js"
   },
@@ -26,5 +27,7 @@ "repository": {
   "devDependencies": {
+    "lodash": "^3.10.1",
+    "protagonist": "^1.2.0",
     "semantic-release": "^6.0.3"
   },
-  "version": "1.0.2"
+  "version": "2.0.0"
 }

README.md

@@ -8,67 +8,106 @@ # account-json-api
 
-This is a [JSON API v1.0](http://jsonapi.org/format/) compliant implementation.
+This is a [JSON API v1.0](http://jsonapi.org/format/) compliant specification
+for a generic REST API for all things user accounts.
 
-## JSON API
+## Summary
 
-Some key information from the spec;
+```
+PUT    /session
+GET    /session
+DELETE /session
+PUT    /session/account
+GET    /session/account
+PATCH  /session/account
+DELETE /session/account
+GET    /session/account/profile
+PATCH  /session/account/profile
 
-> ## Content Negotiation
->
-> ### Client Responsibilities
->
-> Clients **MUST** send all JSON API data in request documents with the header ``Content-Type`: application/vnd.api+json` without any media type parameters.
->
-> Clients that include the JSON API media type in their `Accept` header **MUST** specify the media type there at least once without any media type parameters.
->
-> Clients **MUST** ignore any parameters for the `application/vnd.api+json` media type received in the `Content-Type` header of response documents.
->
-> ### Server Responsibilities
->
-> Servers **MUST** send all JSON API data in response documents with the header `Content-Type: application/vnd.api+json` without any media type parameters.
->
-> Servers **MUST** respond with a 415 Unsupported Media Type status code if a request specifies the header `Content-Type: application/vnd.api+json` with any media type parameters.
->
-> Servers **MUST** respond with a 406 Not Acceptable status code if a request's Accept header contains the JSON API media type and all instances of that media type are modified with media type parameters.
->
-> ## Document Structure
-> ### Top Level
->
-> A JSON object **MUST** be at the root of every JSON API request and response containing data. This object defines a document's "top level".
+# Password resets, upgrades, etc.
+GET    /requests
+POST   /requests
+GET    /requests/{id}
+DELETE /requests/{id}
 
-> A document **MUST** contain at least one of the following top-level members:
+# Admin only
+POST   /accounts
+GET    /accounts
+GET    /accounts/{username}
+PATCH  /accounts/{username}
+DELETE /accounts/{username}
+GET    /accounts/{username}/profile
+PATCH  /accounts/{username}/profile
+```
 
->   - data: the document's "primary data"
->   - errors: an array of error objects
->   - meta: a meta object that contains non-standard meta-information.
->
-> The members data and errors **MUST NOT** coexist in the same document.
->
-> A document **MAY** contain any of these top-level members:
->
->   - jsonapi: an object describing the server's implementation
->   - links: a links object related to the primary data.
->   - included: an array of resource objects that are related to the primary data and/or each other ("included resources").
->
-> If a document does not contain a top-level data key, the included member **MUST NOT** be present either.
+Find the full spec at http://docs.accountjsonapi.apiary.io
 
+## Example
 
-And from the [FAQ](http://jsonapi.org/faq/);
+Request
 
-> ## Where's PUT?
+```
+PUT /session
+Content-Type: application/vnd.api+json
+Accept: application/vnd.api+json
+{
+    "data": {
+        "type": "session",
+        "attributes": {
+            "username": "john-doe",
+            "password": "secret"
+        }
+    }
+}
+```
 
-> Using PUT to partially update a resource (i.e. to change only some of its state) is not allowed by the HTTP specification. Instead, PUT is supposed to completely replace the state of a resource:
+Response
 
-> > “The PUT method requests that the state of the target resource be created or replaced with the state…in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent…”
+```
+{
+    "links": {
+        "self": "https://example.com/session"
+    },
+    "data": {
+        "id": "sessionid123",
+        "type": "session",
+        "relationships": {
+            "account": {
+                "links": {
+                    "related": "https://example.com/session/account"
+                },
+                "data": {
+                    "id": "abc1234",
+                    "type": "account"
+                }
+            }
+        }
+    },
+    "included": [{
+        "id": "abc1234",
+        "type": "account",
+        "attributes": {
+            "username": "jane-doe"
+        },
+        "relationships": {
+            "profile": {
+                "links": {
+                    "related": "https://example.com/session/account/profile"
+                },
+                "data": {
+                    "id": "abc1234-profile",
+                    "type": "accountProfile"
+                }
+            }
+        }
+    }]
+}
+```
 
-> The correct method for partial updates, therefore, is PATCH, which is what JSON API uses. And because PATCH can also be used compliantly for full resource replacement, JSON API hasn't needed to define any behavior for PUT so far. However, it may define PUT semantics in the future.
+## Implementations
 
-> In the past, many APIs used PUT for partial updates because PATCH wasn’t yet well-supported. However, almost all clients now support PATCH, and those that don’t can be [easily worked around](http://jsonapi.org/recommendations/#patchless-clients).
+The `account-json-api` is currently being implemented by [Hoodie](http://hood.ie)
+in the [hoodie-server-account](https://github.com/hoodiehq/hoodie-server-account)
+module.
 
-See documentation on
-http://docs.accountrestapi.apiary.io/
-
-Send your suggestion to the [apiary.apib](apiary.apib) file
-
 ## License
 
 MIT

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Filesystem access

Supply chain risk

Accesses the file system, and could potentially read sensitive data.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Empty package

Supply chain risk

Package does not contain any code. It may be removed, is name squatting, or the result of a faulty package publish.

Found 1 instance in 1 package

Improved metrics

Number of package files

6

increased by20%

Lines of code

31

increased byInfinity%

Number of lines in readme file

113

increased by52.7%

Number of medium supply chain risk alerts

0

decreased by-100%

Worsened metrics

Total package byte prevSize

35637

decreased by-0.18%

Dev dependency count

3

increased by200%

Number of low supply chain risk alerts

1

increased byInfinity%

No dependency changes