research initial api calls

[alishaevn]

summary

determine which api calls will be necessary in order to implement the search, browse, create request and view all/one request features of the mvp.

acceptance criteria

we will need api calls for each of the following scenarios

• [ ] login
• [x] search, per supplier
• [ ] browse, per supplier
• [x] make a request for a single research item
• [x] view all of my requests
• [x] view a request

resources

• https://assaydepot.github.io/scientist_api_docs/
• https://github.com/assaydepot/scientist_api_v2

notes

• we'll be using v2 of the api
• reference for how to access the api using postman or whatever other service you desire: https://assaydepot.github.io/scientist_api_docs/?http#getting-started-location
• each supplier will need their own access token to pass as the "bearer token" in the authorization headers

[alishaevn]

originally posted: sept 9, 2022. last edited: sept 20, 2022.

---

login

• how we're going to handle the login is still up for debate
  • do users create an account on the webstore?
  • if so, where does this get stored?
  • if they already have an account with scientist.com, will they use the same one?
  • SSO or email/password?
• each user will need their own access token to make api calls
  • will we have new access_tokens that are somehow tied to the provider for analytics or anything like that?

update as of 9/20/22:

• we'll be using oauth 2.0 to scientist.com. then scientist.com may delegate this to the supplier (shouldn't require a database)

[alishaevn]

search

return all

- `https://{{domain}}.scientist.com/api/v2/providers/{{provider-id}}/wares.json` - provider id 572 = golden-pacific-services 

request feedback

search for a specific term

- the default way of passing a query to the `/wares` endpoint will not work for our use case (`https://{{domain}}.scientist.com/api/v2/wares.json?q=peptide`) - we instead need to store the list above of available wares. when a user conducts a search, run that query against the list and _not_ the api to return results

[alishaevn]

view all of my requests

this works because of the individual access token that I provide as the "Bearer token" param.

my requests

`https://{{domain}}.scientist.com/api/v2/quote_groups/mine.json` 

[alishaevn]

view a single request

api call for single request

`https://{{domain}}.scientist.com/api/v2/quote_groups/:id.json` 

---

supplier review

• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}.json

mock up


sow selection

• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}.json
• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}/participating_provider.json
• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}/proposals.json
• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}/notes.json

mock up

**1.**  **2.** 

work started

• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}.json
• https://{{domain}}.scientist.com/api/v2/quote_groups/{{quote-group-id}}/quoted_wares/{{quoted-ware-id}}/purchase_orders.json
  mock up

1.

2.

work completed

mock up


[alishaevn]

browse (research areas)

what we have

use the ancestor_slugs value on each category (see: "api result") to determine the path taken to get to the final sub-category. (see: "browser view").

api result

`https://{{domain}}.scientist.com/api/v2/categories.json` 

browser view

| home page | full list page | | ------ | ------ | |  |  |

what we need

request feedback

option a

• "browse" will instead be a visual "search all". (the easier ask and will look more robust for suppliers with fewer items and/or categories)

option b

• get the list of all wares provided by a supplier (ref: "return all" in this comment)
• update that result to also return the ancestor slugs
  • do we want the entire chain of areas or the most specific one? e.g. using the api result above, would we want to reference "toxicology, general-in-vivo-toxicology, large-animal-toxicology1", or only "large-animal-toxicology1"?
  • who handles doing this work?
  • what's the lift?

[alishaevn]

make a request

request feedback

there are 3 ways to make a request:

• clicking on a search result

• clicking on an item (ware) under a research area

  • research area request

  

• https://acme.scientist.com/request (do we need this option for the mvp?)

  • blank request

  

once a user selects the type of thing they want to request, the request form is returned. this logic is not all in the api. it's a mix of controller methods and view logic. dynamic forms are published to certain organizations

• quote_group_controller#new
• quote_groups#add_dynamic_form
• quote_groups/_new_request_form.html.haml

blank request

how does this know what to return?

search request

`ware_refs.urls.storefront` will return the url to redirect to that returns the form. returning that form is based on the linked files above 

browse request

since a browse request is just a grouping of individual services, once we get to the view that shows the services, it'll use the same api call as in "search request" above.

[alishaevn]

spoke with steven about the "make a request" calls above.

request feedback

simply using the rx app as a basis for the webstore api isn't....suggested. there's way too much logic in the views in the rx app.

the api as is, is mainly for reading. we'll need to either update specific controllers to understand json the way we need it, or add create/update functionality to the api.

although the rx-lite repo is outdated (both the react version and the api calls), it might be useful to see how this same/similar idea was being thought about 5 years ago.

[alishaevn]

API enhancements for the webstore mvp

login

• [ ] set up to use oauth 2.0

search

• [ ] be able to search products/services offered by individual supplier's (instead of storing items in the app state and searching through that)
  • e.g.: https://{{base_path}}/providers/20267/wares.json?q=dna

browse

• [ ] the specific wares that a supplier provides should reference the category it relates to
  • e.g. the "ware_refs" property returned at https://{{base_path}}/providers/20267/wares.json should show which category each ware relates to
  • additionally, the "ware_refs" property is incorrect according to chris. it should instead resemble the version of the property returned at https://{{base_path}}/wares.json
  • use the keys in the "facets" property at https://{{base_path}}/wares.json to determine what the categories (research areas) for a ware should be. (some of those facets, like "keywords", shouldn't be there though)

requests

• [ ] create new requests
• [ ] update an existing request
• [ ] cancel (delete?) a request
• [ ] accept an sow
• [ ] send a message to the supplier
• [ ] negotiate an sow
• [ ] submit an sow for approval
• [ ] restart a request

[alishaevn]

talked with @cpetersen and @crisr15 about this. in addition to some new api calls that we need, some of the existing calls are returning results that chris is not expecting. he's going to talk to ron about what changes may need to be made.

once direction is decided, we can create issues against the api v2 repo: https://github.com/assaydepot/scientist_api_v2/issues

[alishaevn]

search

• [ ] https://github.com/assaydepot/scientist_api_v2/issues/158

browse

• [ ] https://github.com/assaydepot/scientist_api_v2/issues/157
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/159

requests

• [ ] https://github.com/assaydepot/scientist_api_v2/issues/160
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/161
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/162
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/163
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/164
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/165
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/166
• [ ] https://github.com/assaydepot/scientist_api_v2/issues/167

[alishaevn]

some of the items in the mock ups in this comment reference a view page and not an api call. e.g., "send message" at the upper left of the supplier review mock up:

• _dashboard_beta_next_actions
  • multiple recipients modal
  • _dashboard_beta_multiple_recipient_message
    • quote_group_notes_path??