Sprint #1 - Daily Scrum #16

Product: CMS API
Sprint Summary

Daily Objectives

• Fill out Microservice Descriptions
• Fill out Data Design Sections
• Fill out Interface Design Section
• Output PDF’s for Scrums and write Sprint Summary
• Update website and resume

Notes

Quick Refresher Questions:

1. How am I storing references to resources to create permissions for in the user and roles management service?
   I can either keep a small updated reference in the user and roles management service of the resources in the content types or just keep a reference of their ID’s.
2. Where/When do I check for permissions?
   Logged In User in the AdminUI will create the request and send it to the API Gateway. The API Gateway checks to make sure the user is logged in, should the API Gateway will then use the User Roles to double check they have the permissions and then pass the request over to the REST API with the OK.

I still need to make a Database Design Schema for the User, Roles, and Permissions table and explain somewhere how they’re referencing project resources.
Just to note somewhere, some other design documents seem to ramble a bit on their design so I feel a little more enabled to speak more freely on this document.

Let’s talk about API Design again. Key Concepts: Resource Models

1. Singleton Resource
2. Collection of Resources
3. Sub-collections and Sub-resources

Common formats:

1. JSON
2. YAML
3. XML

HTTP Methods

1. POST - create new object
2. GET - read
3. PUT - update/replace
4. PATCH - partial update/modify
5. DELETE - delete item

General Tips and Practices:

1. Use links as a sub resource to represent relationships with other resources
2. Consider creating a Metadata resource for use in drop down menus and the like

Before referencing my previous notes, let’s go over what I feel like the Resources would be:

• Collection of Projects
• Project
• Collection of Project Pages (for a Project)
• Collection of ProjectCollections (for a Project)
• Collection of Media Uploads
• Project Page
• Project Collection
• Collection of Page/Collection Entries ()
• There’s no need to create a resource endpoint for entry items

Process for designing RESTful API’s

1. Identify Object Model
   • Done right above
2. Create Model URIs
   • Can do that easily right above
3. Determine Representations
   • JSON, YAML, XML
4. Assign HTTP Methods
   • Describe what HTTP methods do for each resource and other parameters
5. More Actions
   • Authenticating Session based requests: browser usually sends cookie session id with their request

Authenticating Requests btw

Objectives Completed

• created data design chart/graph for the user and roles service using the LucidCharts webapp

• discussed and finalized authentication flow through the microservice architecture

• researched more information on RESTful API design including the resources and design process