This is a blog API.
\nThe general idea here is that the API has a general endpoint that shows a list of articles that have been created by different people, and anybody that calls this endpoint, should be able to read a blog created by them or other users.
\n","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","toc":[],"owner":"22961306","collectionId":"d424d54a-870e-401b-93f7-496f074716d5","publishedId":"2s8YYFs47Y","public":true,"customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"EF5B25"},"publishDate":"2022-11-05T18:24:24.000Z"},"item":[{"name":"Create A New User","id":"59e7cb01-7b85-40f0-845b-8ed90610741c","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"POST","header":[],"body":{"mode":"raw","raw":"{\r\n \"first_name\": \"Olaitan\",\r\n \"last_name\": \"Ade\",\r\n \"email\": \"kenney9224@gmail.com\",\r\n \"password\": \"Abc-1234\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/user/signup","description":"The Signup endpoint enables a user to register and create a blog successfully. Upon successful registration, an authentication token will be provided, allowing the user to access other necessary endpoints. This endpoint expects the following fields in the request body:
\nuser_name (string): The username of the user.email (string): The email address of the user.password (string): The password for the user. It should be a minimum of 8 characters and may include a combination of uppercase letters, lowercase letters, numbers, and special characters./api/signupExample Request Body:
\n{\n \"first_name\": \"John\",\n \"last_name\": \"Doe\",\n \"email\": \"johndoe@example.com\",\n \"password\": \"Abc-1234\"\n}\n\nThis endpoint give access to a client to access other endpoints on the application if details provided are correct and the user still exist.
\nIf successful, the author ID/blog owner and a token is returned.
\n\n\nToken expires in 1 hour
\n
See example request and response
\n","urlObject":{"port":"2000","path":["api","v1","user","login"],"host":["localhost"],"query":[],"variable":[]}},"response":[{"id":"41344e18-086f-48ca-aab2-2a275c108f08","name":"Login A User","originalRequest":{"method":"POST","header":[],"body":{"mode":"raw","raw":"{\r\n \"email\": \"kenney9224@gmail.com\",\r\n \"password\": \"Abc-1234\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/user/login"},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"241"},{"key":"ETag","value":"W/\"f1-RAQbbxDIWCNhXXHrHa/2tgcVUzc\""},{"key":"Date","value":"Sat, 05 Nov 2022 12:12:10 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"author_id\": \"636652df776e6b09fecc6c70\",\n \"token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjY1MmRmNzc2ZTZiMDlmZWNjNmM3MCIsImlhdCI6MTY2NzY1MDMzMCwiZXhwIjoxNjY3NjUzOTMwfQ.oew2YHUZgOdHFJ3VA_qPlMug3RTQzNnquEobvubUnVM\"\n}"}],"_postman_id":"e446601d-7639-4782-b93a-01c88cbe5e85"},{"name":"Create A Blog Post","id":"dbb76cb7-9b0d-4a92-b172-baddea3087b0","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"POST","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjY1MmRmNzc2ZTZiMDlmZWNjNmM3MCIsImlhdCI6MTY2NzY2NTQyNCwiZXhwIjoxNjY3NjY5MDI0fQ.S0IFskvo0obnp2KN6AX6MVX74pSbipBnItINtt9JEgg","type":"text"}],"body":{"mode":"raw","raw":"{\r\n \"title\": \"Lorem Ipsum 5\",\r\n \"description\": \"What is Lorem Ipsum 5?\",\r\n \"state\": \"published\",\r\n \"tags\": [\r\n \"Free-text\",\r\n \"Jargons\",\r\n \"Web Work\"\r\n ],\r\n \"body\": \"Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.\\n\\nWhy do we use it?\\nIt is a long established fact that a reader will be distracted by the readable content of a page when looking at its layout. The point of using Lorem Ipsum is that it has a more-or-less normal distribution of letters, as opposed to using 'Content here, content here', making it look like readable English. Many desktop publishing packages and web page editors now use Lorem Ipsum as their default model text, and a search for 'lorem ipsum' will uncover many web sites still in their infancy. Various versions have evolved over the years, sometimes by accident, sometimes on purpose (injected humour and the like).Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.\\n\\nWhy do we use it?\\nIt is a long established fact that a reader will be distracted by the readable content of a page when looking at its layout. The point of using Lorem Ipsum is that it has a more-or-less normal distribution of letters, as opposed to using 'Content here, content here', making it look like readable English. Many desktop publishing packages and web page editors now use Lorem Ipsum as their default model text, and a search for 'lorem ipsum' will uncover many web sites still in their infancy. Various versions have evolved over the years, sometimes by accident, sometimes on purpose (injected humour and the like).\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/blogs/create","description":"This endpoint is protected. Only a logged in user can access. Please register, login and/or provide a valid token to continue.
\nThis route enables a registered user to create a blog post successfully. Token to be send as an authorization header.
\nIf successful, the details of the blog post is returned to the client.
\nSee example request and response.
\n","urlObject":{"port":"2000","path":["api","v1","blogs","create"],"host":["localhost"],"query":[],"variable":[]}},"response":[{"id":"b5bea8f9-a2b9-47eb-90cc-0a108086acc1","name":"Create A Blog Post","originalRequest":{"method":"POST","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjQwNWY5NTE5MTg0MzcwNWRhMTU2OSIsImlhdCI6MTY2NzUwMDIxNywiZXhwIjoxNjY3NTAzODE3fQ.sZzcmKYcK816VcYE9k_XOxlCsyetgjnXsAyKZfG3TE4","type":"text"}],"body":{"mode":"raw","raw":"{\r\n \"title\": \"How to Use JavaScript some Method 3\",\r\n \"author_id\": \"63604d4b3d61a593761cf3b3\",\r\n \"description\": \"JavaScript some() With thisArg Argument\",\r\n \"state\": \"published\",\r\n \"tags\": [\r\n \"JavaScript\",\r\n \"Web Development\",\r\n \"Programming Blogs\",\r\n \"Beginner Developers\",\r\n \"Tutorial\"\r\n ],\r\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/blogs/create"},"status":"Created","code":201,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"2425"},{"key":"ETag","value":"W/\"979-VsRPUozb5tIyGFFIqOIOkvd8W4U\""},{"key":"Date","value":"Thu, 03 Nov 2022 18:36:06 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"data\": {\n \"user\": {\n \"title\": \"How to Use JavaScript some Method 3\",\n \"description\": \"JavaScript some() With thisArg Argument\",\n \"author\": \"636405f95191843705da1569\",\n \"state\": \"published\",\n \"read_count\": 0,\n \"tags\": [\n \"JavaScript\",\n \"Web Development\",\n \"Programming Blogs\",\n \"Beginner Developers\",\n \"Tutorial\"\n ],\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\",\n \"timestamp\": \"2022-11-03T18:29:34.999Z\",\n \"_id\": \"63640a16132aeb0b678e819d\",\n \"__v\": 0\n }\n }\n}"}],"_postman_id":"dbb76cb7-9b0d-4a92-b172-baddea3087b0"},{"name":"Get All Blog Posts","event":[{"listen":"test","script":{"id":"ede88141-c069-41f0-a59a-d6e4b866e568","exec":[""],"type":"text/javascript"}}],"id":"a376ebc5-d7a2-4964-a64d-c789fb3046bb","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"GET","header":[],"url":"{{URL}}/api/v1/blogs/","description":"The endpoint enables both logged in users and not logged in users to be able to get a list of published blogs.
\nThe list of all blogs where state is published is returned to the client.
See example request and response.
\n","urlObject":{"path":["api","v1","blogs",""],"host":["{{URL}}"],"query":[{"disabled":true,"key":"description","value":"What is Lorem Ipsum?"}],"variable":[]}},"response":[{"id":"9f8e1e0f-36e5-4353-8da3-75d27fd616f5","name":"Get All Blog Posts","originalRequest":{"method":"GET","header":[],"url":"localhost:2000/api/v1/blogs"},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"4907"},{"key":"ETag","value":"W/\"132b-e2H2hlLc9vGAs/tlJRBYpsp2fL8\""},{"key":"Date","value":"Thu, 03 Nov 2022 18:40:06 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"length\": 2,\n \"data\": {\n \"blogs\": [\n {\n \"_id\": \"63640a16132aeb0b678e819d\",\n \"title\": \"How to Use JavaScript some Method 3\",\n \"description\": \"JavaScript some() With thisArg Argument\",\n \"author\": {\n \"_id\": \"636405f95191843705da1569\",\n \"first_name\": \"Olaitan\",\n \"last_name\": \"Ade\"\n },\n \"state\": \"published\",\n \"read_count\": 0,\n \"tags\": [\n \"JavaScript\",\n \"Web Development\",\n \"Programming Blogs\",\n \"Beginner Developers\",\n \"Tutorial\"\n ],\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\",\n \"timestamp\": \"2022-11-03T18:29:34.999Z\"\n },\n {\n \"_id\": \"6363e2ba5191843705da155d\",\n \"title\": \"How to Use JavaScript some Method 2\",\n \"description\": \"JavaScript some() With thisArg Argument\",\n \"author\": {\n \"_id\": \"6363c5d4e1f8a334f4253f0d\",\n \"first_name\": \"Ada\",\n \"last_name\": \"Ikem\"\n },\n \"state\": \"published\",\n \"read_count\": 0,\n \"tags\": [\n \"JavaScript\",\n \"Web Development\",\n \"Programming Blogs\",\n \"Beginner Developers\",\n \"Tutorial\"\n ],\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\",\n \"timestamp\": \"2022-11-03T15:04:29.189Z\"\n }\n ]\n }\n}"}],"_postman_id":"a376ebc5-d7a2-4964-a64d-c789fb3046bb"},{"name":"Get a Blog Post","id":"00c27197-c691-4de8-819c-d8d7cf639cc8","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"GET","header":[],"url":"localhost:2000/api/v1/blogs/63665992774eadb0d4045db4","description":"This endpoint enabled both logged in and not logged in users should be able to get a published blog.
\nAs a query to the endpoint, the blog ID should be passed. You can request for all blogs to select a particular blog to access individually.
\nIf successful, a detailed response of the blog is sent to the client.
\n\n\nThis request increase the count on this blog
\n
See sample request and response.
\n","urlObject":{"port":"2000","path":["api","v1","blogs","63665992774eadb0d4045db4"],"host":["localhost"],"query":[],"variable":[]}},"response":[{"id":"75613068-ee46-4aab-b0e2-e9c6daaf701a","name":"Get a Blog Post","originalRequest":{"method":"GET","header":[],"url":"localhost:2000/api/v1/blogs/6363e2ba5191843705da155d"},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"2425"},{"key":"ETag","value":"W/\"979-jY0V6+JcWvHAWhBsUof2hQJ8XEo\""},{"key":"Date","value":"Thu, 03 Nov 2022 18:52:11 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"data\": {\n \"blog\": {\n \"_id\": \"6363e2ba5191843705da155d\",\n \"title\": \"How to Use JavaScript some Method 2\",\n \"description\": \"JavaScript some() With thisArg Argument\",\n \"author\": \"6363c5d4e1f8a334f4253f0d\",\n \"state\": \"published\",\n \"read_count\": 3,\n \"tags\": [\n \"JavaScript\",\n \"Web Development\",\n \"Programming Blogs\",\n \"Beginner Developers\",\n \"Tutorial\"\n ],\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\",\n \"timestamp\": \"2022-11-03T15:04:29.189Z\",\n \"__v\": 0\n }\n }\n}"}],"_postman_id":"00c27197-c691-4de8-819c-d8d7cf639cc8"},{"name":"Login User Update a Blog-post","id":"d7e02b4d-b080-4daf-9551-1ea1a2540f81","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"PUT","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjY1MmRmNzc2ZTZiMDlmZWNjNmM3MCIsImlhdCI6MTY2NzY2NTQyNCwiZXhwIjoxNjY3NjY5MDI0fQ.S0IFskvo0obnp2KN6AX6MVX74pSbipBnItINtt9JEgg","type":"text"}],"body":{"mode":"raw","raw":"{\r\n \"read_count\": 4,\r\n \"description\": \"Javascript get levels ooo\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/blogs/6366550e776e6b09fecc6c7b","description":"The endpoint is only for blog owners and registered users.
The owner of the blog should be able to update the state of the blog to published by providing the ID of the blog to update and a body that is the state.
The owner of a blog should be able to edit the blog in draft or published state.
The owner of a blog should be able to edit the blog in draft or published state
\nTo get the list of all the user's blogs, visit blogs/all
If successful, the updated blog details will be returned to the client.
\n\n\nPlease provide the token received upon successful login or registration to update a blog
\n
See sample requests and responses
\n","urlObject":{"port":"2000","path":["api","v1","blogs","6366550e776e6b09fecc6c7b"],"host":["localhost"],"query":[],"variable":[]}},"response":[{"id":"80885bd0-b62f-4999-9478-9fb6efd7a313","name":"Login User Update a Blog-post","originalRequest":{"method":"PUT","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjQwNWY5NTE5MTg0MzcwNWRhMTU2OSIsImlhdCI6MTY2NzUwMDIxNywiZXhwIjoxNjY3NTAzODE3fQ.sZzcmKYcK816VcYE9k_XOxlCsyetgjnXsAyKZfG3TE4","type":"text"}],"body":{"mode":"raw","raw":"{\r\n \"state\": \"published\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/blogs/636409d2132aeb0b678e8191"},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"2433"},{"key":"ETag","value":"W/\"981-qcAR+pfe+f0EktE1PsbHdXEJ9u0\""},{"key":"Date","value":"Thu, 03 Nov 2022 19:13:41 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"data\": {\n \"updatedArticle\": {\n \"_id\": \"636409d2132aeb0b678e8191\",\n \"title\": \"How to Use JavaScript some Method\",\n \"description\": \"JavaScript some() With thisArg Argument\",\n \"author\": \"636405f95191843705da1569\",\n \"state\": \"published\",\n \"read_count\": 0,\n \"tags\": [\n \"JavaScript\",\n \"Web Development\",\n \"Programming Blogs\",\n \"Beginner Developers\",\n \"Tutorial\"\n ],\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\",\n \"timestamp\": \"2022-11-03T18:29:34.999Z\",\n \"__v\": 0\n }\n }\n}"},{"id":"dfcd6b45-c92d-4c1f-a484-fc6ef7f46142","name":"Login User Update a Blog-post","originalRequest":{"method":"PUT","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjQwNWY5NTE5MTg0MzcwNWRhMTU2OSIsImlhdCI6MTY2NzUwMzgzMSwiZXhwIjoxNjY3NTA3NDMxfQ.A4cRUuYfRf1OuglqTj3ItTu9HG3g7OqXD9ZviBME4-I","type":"text"}],"body":{"mode":"raw","raw":"{\r\n \"state\": \"draft\",\r\n \"description\": \"JavaScript With A Test\"\r\n}","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/blogs/636409d2132aeb0b678e8191"},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"2412"},{"key":"ETag","value":"W/\"96c-gT2ubNeqQEV2iuoLIwcFT8Z2nwQ\""},{"key":"Date","value":"Thu, 03 Nov 2022 19:47:37 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"data\": {\n \"updatedArticle\": {\n \"_id\": \"636409d2132aeb0b678e8191\",\n \"title\": \"How to Use JavaScript some Method\",\n \"description\": \"JavaScript With A Test\",\n \"author\": \"636405f95191843705da1569\",\n \"state\": \"draft\",\n \"read_count\": 0,\n \"tags\": [\n \"JavaScript\",\n \"Web Development\",\n \"Programming Blogs\",\n \"Beginner Developers\",\n \"Tutorial\"\n ],\n \"body\": \"When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How do your service know if a match exists, if the info isn't directly stored in your domain model?\\nThis exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project, and wanted to explain how it works.\\n\\nI want to be able to search for one or more search terms and get Cards back that match the search terms.\\nOne might search for word(s) that is contained in the title of the card. This is easy to implement, as title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.\\nYou could simply argue \\\"Well maybe the author's name is part of the domain model!\\\". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.\\nvery simple domain model simply containing a card with a title, description and author identifier\\nWhen i search for a full or subpart of an author's name, or part of a title, I want all cards that match all query terms, so I can find the cards i am looking for.\",\n \"timestamp\": \"2022-11-03T18:29:34.999Z\",\n \"__v\": 0\n }\n }\n}"}],"_postman_id":"d7e02b4d-b080-4daf-9551-1ea1a2540f81"},{"name":"Delete A Blog Post","id":"e96b9e24-e86f-4338-ba02-6f8cbcb59990","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"DELETE","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjY1MmRmNzc2ZTZiMDlmZWNjNmM3MCIsImlhdCI6MTY2NzY2NTQyNCwiZXhwIjoxNjY3NjY5MDI0fQ.S0IFskvo0obnp2KN6AX6MVX74pSbipBnItINtt9JEgg","type":"text"}],"url":"localhost:2000/api/v1/blogs/6366620d5b133505312c2987","description":"This endpoint allows the owner of the blog to be able to delete the blog in draft or published state.
\nUser must be logged in. i.e. a valid token should be sent along with the id as a query to the endpoint.
\nIf successful, a success response will be sent to the client with the deleted blog ID.
\nThis action will also remove the blog under the author's details.
\n\n\nToken expires in 1 hour
\n
See sample request and response
\n","urlObject":{"port":"2000","path":["api","v1","blogs","6366620d5b133505312c2987"],"host":["localhost"],"query":[],"variable":[]}},"response":[{"id":"44432670-e475-44b0-b888-f5448cd16c8a","name":"Delete A Blog Post","originalRequest":{"method":"DELETE","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjQwNWY5NTE5MTg0MzcwNWRhMTU2OSIsImlhdCI6MTY2NzUwMzgzMSwiZXhwIjoxNjY3NTA3NDMxfQ.A4cRUuYfRf1OuglqTj3ItTu9HG3g7OqXD9ZviBME4-I","type":"text"}],"url":"localhost:2000/api/v1/blogs/636409d2132aeb0b678e8191"},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"X-Powered-By","value":"Express"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"65"},{"key":"ETag","value":"W/\"41-I7qDOrBs8vDMFTxPUbhkP+3ozpw\""},{"key":"Date","value":"Thu, 03 Nov 2022 20:05:12 GMT"},{"key":"Connection","value":"keep-alive"},{"key":"Keep-Alive","value":"timeout=5"}],"cookie":[],"responseTime":null,"body":"{\n \"status\": \"success\",\n \"data\": {\n \"blogID\": \"636409d2132aeb0b678e8191\"\n }\n}"}],"_postman_id":"e96b9e24-e86f-4338-ba02-6f8cbcb59990"},{"name":"Owner's Blog List","id":"ae23eb81-d4f8-43a8-a6ad-6c59b3762c9d","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"auth":{"type":"bearer","bearer":{"basicConfig":[{"key":"token","value":"{{jwt}}"}]},"isInherited":false},"method":"GET","header":[{"key":"Authorization","value":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYzNjY1MmRmNzc2ZTZiMDlmZWNjNmM3MCIsImlhdCI6MTY2NzY2NTQyNCwiZXhwIjoxNjY3NjY5MDI0fQ.S0IFskvo0obnp2KN6AX6MVX74pSbipBnItINtt9JEgg","type":"text"}],"body":{"mode":"raw","raw":"","options":{"raw":{"language":"json"}}},"url":"localhost:2000/api/v1/blogs/all?state=draft","description":"This endpoint allows the owner of the blog to be able to get a list of their blogs. \nThe endpoint is paginated and client can send a query with the page number and can be filtered by state.
\n\n\nA token must be provided to access this route
\n
See sample requests and responses.
\n","urlObject":{"port":"2000","path":["api","v1","blogs","all"],"host":["localhost"],"query":[{"key":"state","value":"draft"}],"variable":[]}},"response":[],"_postman_id":"ae23eb81-d4f8-43a8-a6ad-6c59b3762c9d"}]}