Your best bet is always the documentation. REST isn't exactly a standard as much as it is a set of guidelines. Basically your entities are each given their own endpoints e.g:
- https://ww.api.com/customer
- https://ww.api.com/product
- https://ww.api.com/cart
You can use HTTP verbs to do things on these endpoints.
- GET will return the entity
- POST will insert a new entity
- PUT will update the entire entity (many API will get this wrong, you should supply all properties)
- PATCH will do a partial update on the entity (just the properties you send)
- DELETE will delete the entity
Note that usually your models won't exactly fit this or would require multiple round-trips so you'll make one-off endpoints that only accept some of these verbs for ease of use. Sometimes you need to change things, for example GETs use querystring params which may be undesirable so you use a POST to retrieve info instead etc. The most ideal is one endpoint per entity and your API should be "discoverable" meaning that all entities can be known by just starting traversal at one endpoint, again not always on the table but try your best. One last thing you can look into is webhooks. Webhooks let the client submit a callback url, so for example when an object changes it might POST to that url on your server letting you know it has updated.
The secret key has more to do with Oauth. Oauth like REST is a set of guidelines but everyone does it differently so you need to read the specific documentation. The flow might be different for web apps than servers.
For example a web app might:
- Request auth with API key and scope (set of permission). This is usually a redirect to a login form.
- User inputs credentials
- Redirects back to app with Oauth key which you can then use to access the rest of the API.
A server app might
- Request one-time auth key
- Use auth key to exchange for long term oauth key
- Use oauth key to access rest of API
In each case you typically have to construct the response in highly particular way. There is a general process for creating a signature that's a tad complicated. There's usually a requirement for nonces which are generated values that can be used exactly one do deter replay attacks. The types of hashes allowed might vary, or sometime you send the variables as a query string or sometimes as headers. Again, read the documentation. There's probably a library that can help you to do these things unless it's via javascript then you have to write your own.
