#8 and #16 - Retrieve and delete artifacts by artifact ID

[gk-per]

connects to #8 and #16

What I'm doing:

• add api_delete to client.ex
• add retrieving and deleting artifact by id
• alphabetize prodops_ex.ex fns

What it looks like:
Retrieve:

iex(2)> ProdopsEx.get_artifact_by_id(%{artifact_slug: "story", artifact_id: 4739}, %ProdopsEx.Config{bearer_token: "api_key"})
{:ok,
 %{
   status: "ok",
   response: %{
     "artifact" => %{
       "chat_history" => [
         %{
           "content" => "You are going to be a product manager and write a BDD-style user story for our project. You pride yourself in your ability to write concise stories. \n\nTo be more concise, you write as few scenarios as possible. For example, if there are 3 similar things that should be done, you combine them into one scenario. \n\nYou are also terse when writing the background. You do not use business jargon or flowery language, and you do not wax long. You are terse.\n\nThe purpose of the story you're writing is: Engineer - ProdOps-SDK - Document Upload Support\n\nPotentially: more info about what this story is to accomplish and how: Can you write a user story about updating the prodops sdk that calls for adding support for a document upload function that leverages the document upload endpoint that takes in a file in the request body /api/v1/data_center/documents/upload\n\nBelow are some details about our project to help you write a story that is tailored to the app we're building.\n\nProject Name: ProdOps-SDK-Elixir\n\n--- BEGIN: Project Overview ---\nFor dev work around the Elixir SDK\n--- END: Project Overview ---\n\nBelow is a sample story you can use as an example of how to structure and format the story, and to give an idea of the granularity required. The sample issue includes background section, which every story should have, and some Acceptance Criteria organized into scenarios. Each scenario maps to one or more of the key objectives of the feature, with the various steps outlined as individual AC in BDD style. \n\nDifferent stories may have different numbers of scenarios depending on what kinds of functionality they specify. Please note the sample story is for a different app, so you should not carry any of the specific concepts, affordances, or user actions over into the generated story unless they fit with the project info described above.\n\n--------- BEGIN: Sample Story ---------\n## Background\nEnable real-time UI updates on the Document Index Page when users add documents to collections.\n\n## Acceptance Criteria\n\n### Scenario: Real-time UI update when adding documents to a collection\n- [ ] Given I am a user on the Document Index Page\n- [ ] When I select one or more documents and add them to an existing collection\n- [ ] Then the Document Index Page should refresh the UI dynamically to show the documents as part of the target collection instantly\n- [ ] And the change should be reflected without any manual page reloads or additional user actions. \n\n--------- END: Sample Story ---------\n\nTake a deep breath, and think through the scenarios step-by-step. Remember - keep the background simple and easy to understand.",
           "role" => "user"
         },
         %{
           "content" => "## Background\nIntegrate document upload functionality into the ProdOps-SDK-Elixir to allow file uploads to the /api/v1/data_center/documents/upload endpoint.\n\n## Acceptance Criteria\n\n### Scenario: Document upload via ProdOps-SDK-Elixir\n- [ ] Given the ProdOps-SDK-Elixir is set up and authenticated\n- [ ] When a developer calls the document upload function with a valid file \n- [ ] Then the SDK should send an HTTP POST request with the file in the request body to /api/v1/data_center/documents/upload\n- [ ] And the server should respond with a success status if the upload is successful\n- [ ] And the SDK should handle any server errors or exceptions and provide appropriate feedback to the developer.",
           "role" => "assistant"
         }
       ],
       "content" => "## Background\nIntegrate document upload functionality into the ProdOps-SDK-Elixir to allow file uploads to the /api/v1/data_center/documents/upload endpoint.\n\n## Acceptance Criteria\n\n### Scenario: Document upload via ProdOps-SDK-Elixir\n- [ ] Given the ProdOps-SDK-Elixir is set up and authenticated\n- [ ] When a developer calls the document upload function with a valid file \n- [ ] Then the SDK should send an HTTP POST request with the file in the request body to /api/v1/data_center/documents/upload\n- [ ] And the server should respond with a success status if the upload is successful\n- [ ] And the SDK should handle any server errors or exceptions and provide appropriate feedback to the developer.",
       "id" => 4739,
       "manually_edited" => false,
       "name" => "Engineer - ProdOps-SDK - Document Upload Support Integration",
       "notes" => nil,
       "share_token" => nil
     }
   }
 }}

Delete:

iex(2)> ProdopsEx.delete_artifact_by_id(
...(2)>     %{artifact_slug: "story", artifact_id: 4754},
...(2)>     %ProdopsEx.Config{
...(2)>       bearer_token: "api_key",
...(2)>     }
...(2)>   )
{:ok,
 %{status: "ok", response: %{"message" => "Artifact deleted successfully."}}}

What I'd like feedback on:

• Anything and everything you might have questions about

[estreeper]

Nice, looks good!

There may be a bit we'll need to do to reconcile this with #22 , but nothing too crazy. If we merge this in first I can handle merging in the changes to that branch.

[gk-per]

@estreeper sounds good, I'll merge this in if you're find handling the potential conflicts on the 9-artifact-create branch