Mixing
Spring-Data @RepositoryRestResource deleteByName uses wrong HTTP-Method when deleting a resource
0
I'm faced with a scenario where the custom @RepositoryRestResource interface-method is involved by the wrong HTTP-Method. For example:
@RepositoryRestResource(path = "matches", collectionResourceRel = "matches")
public interface MatchRepo extends Neo4jRepository<Match, Long> {
Collection<Match> findAllByCodeName(@Param("codeName") String codeName);
@Transactional
Long deleteAllByCodeName(@Param("codeName") String codeName);
}
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1'
Note the above GET HTTP-Method. This is expected, & i'm happy with the Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:32:49 GMT
{
"_embedded" : {
"matches" : [ {
"id" : "1",
"codeName" : "Test-CodeName-1",
"round" : 1,
"me" : "ROCK",
"pc" : "ROCK",
"result" : "D",
"timestamp" : "Nov 20, 2018, 05:32:27 AM",
"lastUpdated" : "Nov 20, 2018, 05:32:27 AM",
"created" : "Nov 20, 2018, 05:32:27 AM",
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
},
"match" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1"
}
}
}%
This is what appears on the Intelli-J Console-Mappings:
http://localhost:8003/spring-data/api/v1/{repository}/search
& I implemented the request as indicated in the mappings, as shown below. But the problem becomes evident when I am deleting a resource with a GET HTTP-Method as shown below:
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/deleteAllByCodeName?codeName=Test-CodeName-1'
Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:51:33 GMT
{
"10":
}
I need to find a way to make my custom deleteAllByCodeName(@Param) interface-method from the MatchRepo class to execute with the correct HTTP-Method. Must use DELETE HTTP-Method & not the GET HTTP-Method and adhere to the REST-API Design Principles.
spring-data spring-data-rest spring-data-neo4j spring-hateoas spring-repositories
asked Nov 20 '18 at 16:02
S34NS34N
496613
add a comment |
0
I'm faced with a scenario where the custom @RepositoryRestResource interface-method is involved by the wrong HTTP-Method. For example:
@RepositoryRestResource(path = "matches", collectionResourceRel = "matches")
public interface MatchRepo extends Neo4jRepository<Match, Long> {
Collection<Match> findAllByCodeName(@Param("codeName") String codeName);
@Transactional
Long deleteAllByCodeName(@Param("codeName") String codeName);
}
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1'
Note the above GET HTTP-Method. This is expected, & i'm happy with the Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:32:49 GMT
{
"_embedded" : {
"matches" : [ {
"id" : "1",
"codeName" : "Test-CodeName-1",
"round" : 1,
"me" : "ROCK",
"pc" : "ROCK",
"result" : "D",
"timestamp" : "Nov 20, 2018, 05:32:27 AM",
"lastUpdated" : "Nov 20, 2018, 05:32:27 AM",
"created" : "Nov 20, 2018, 05:32:27 AM",
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
},
"match" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1"
}
}
}%
This is what appears on the Intelli-J Console-Mappings:
http://localhost:8003/spring-data/api/v1/{repository}/search
& I implemented the request as indicated in the mappings, as shown below. But the problem becomes evident when I am deleting a resource with a GET HTTP-Method as shown below:
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/deleteAllByCodeName?codeName=Test-CodeName-1'
Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:51:33 GMT
{
"10":
}
I need to find a way to make my custom deleteAllByCodeName(@Param) interface-method from the MatchRepo class to execute with the correct HTTP-Method. Must use DELETE HTTP-Method & not the GET HTTP-Method and adhere to the REST-API Design Principles.
spring-data spring-data-rest spring-data-neo4j spring-hateoas spring-repositories
asked Nov 20 '18 at 16:02
S34NS34N
496613
add a comment |
0
0
0
I'm faced with a scenario where the custom @RepositoryRestResource interface-method is involved by the wrong HTTP-Method. For example:
@RepositoryRestResource(path = "matches", collectionResourceRel = "matches")
public interface MatchRepo extends Neo4jRepository<Match, Long> {
Collection<Match> findAllByCodeName(@Param("codeName") String codeName);
@Transactional
Long deleteAllByCodeName(@Param("codeName") String codeName);
}
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1'
Note the above GET HTTP-Method. This is expected, & i'm happy with the Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:32:49 GMT
{
"_embedded" : {
"matches" : [ {
"id" : "1",
"codeName" : "Test-CodeName-1",
"round" : 1,
"me" : "ROCK",
"pc" : "ROCK",
"result" : "D",
"timestamp" : "Nov 20, 2018, 05:32:27 AM",
"lastUpdated" : "Nov 20, 2018, 05:32:27 AM",
"created" : "Nov 20, 2018, 05:32:27 AM",
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
},
"match" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1"
}
}
}%
This is what appears on the Intelli-J Console-Mappings:
http://localhost:8003/spring-data/api/v1/{repository}/search
& I implemented the request as indicated in the mappings, as shown below. But the problem becomes evident when I am deleting a resource with a GET HTTP-Method as shown below:
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/deleteAllByCodeName?codeName=Test-CodeName-1'
Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:51:33 GMT
{
"10":
}
I need to find a way to make my custom deleteAllByCodeName(@Param) interface-method from the MatchRepo class to execute with the correct HTTP-Method. Must use DELETE HTTP-Method & not the GET HTTP-Method and adhere to the REST-API Design Principles.
spring-data spring-data-rest spring-data-neo4j spring-hateoas spring-repositories
asked Nov 20 '18 at 16:02
S34NS34N
496613
I'm faced with a scenario where the custom @RepositoryRestResource interface-method is involved by the wrong HTTP-Method. For example:
@RepositoryRestResource(path = "matches", collectionResourceRel = "matches")
public interface MatchRepo extends Neo4jRepository<Match, Long> {
Collection<Match> findAllByCodeName(@Param("codeName") String codeName);
@Transactional
Long deleteAllByCodeName(@Param("codeName") String codeName);
}
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1'
Note the above GET HTTP-Method. This is expected, & i'm happy with the Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:32:49 GMT
{
"_embedded" : {
"matches" : [ {
"id" : "1",
"codeName" : "Test-CodeName-1",
"round" : 1,
"me" : "ROCK",
"pc" : "ROCK",
"result" : "D",
"timestamp" : "Nov 20, 2018, 05:32:27 AM",
"lastUpdated" : "Nov 20, 2018, 05:32:27 AM",
"created" : "Nov 20, 2018, 05:32:27 AM",
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
},
"match" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/22"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8003/spring-data/api/v1/matches/search/findAllByCodeName?codeName=Test-CodeName-1"
}
}
}%
This is what appears on the Intelli-J Console-Mappings:
http://localhost:8003/spring-data/api/v1/{repository}/search
& I implemented the request as indicated in the mappings, as shown below. But the problem becomes evident when I am deleting a resource with a GET HTTP-Method as shown below:
Request:
curl -i -X GET 'http://localhost:8003/spring-data/api/v1/matches/search/deleteAllByCodeName?codeName=Test-CodeName-1'
Response:
HTTP/1.1 200
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2018 15:51:33 GMT
{
"10":
}
I need to find a way to make my custom deleteAllByCodeName(@Param) interface-method from the MatchRepo class to execute with the correct HTTP-Method. Must use DELETE HTTP-Method & not the GET HTTP-Method and adhere to the REST-API Design Principles.
spring-data spring-data-rest spring-data-neo4j spring-hateoas spring-repositories
spring-data spring-data-rest spring-data-neo4j spring-hateoas spring-repositories
asked Nov 20 '18 at 16:02
S34NS34N
496613
asked Nov 20 '18 at 16:02
S34NS34N
496613
asked Nov 20 '18 at 16:02
S34NS34N
496613
asked Nov 20 '18 at 16:02
S34NS34N
496613
asked Nov 20 '18 at 16:02
S34NS34N
496613
496613
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
0
The manual notes that search resources only support GET requests.
https://docs.spring.io/spring-data/rest/docs/3.1.2.RELEASE/reference/html/#repository-resources.search-resource
You can prevent this repo method from being exported:
@RestResource(exported = false)
Long deleteAllByCodeName(@Param("codeName") String codeName);
and create a normal Spring MVC controller that handles the delete request.
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
1
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53396933%2fspring-data-repositoryrestresource-deletebyname-uses-wrong-http-method-when-del%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
The manual notes that search resources only support GET requests.
https://docs.spring.io/spring-data/rest/docs/3.1.2.RELEASE/reference/html/#repository-resources.search-resource
You can prevent this repo method from being exported:
@RestResource(exported = false)
Long deleteAllByCodeName(@Param("codeName") String codeName);
and create a normal Spring MVC controller that handles the delete request.
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
1
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
add a comment |
0
The manual notes that search resources only support GET requests.
https://docs.spring.io/spring-data/rest/docs/3.1.2.RELEASE/reference/html/#repository-resources.search-resource
You can prevent this repo method from being exported:
@RestResource(exported = false)
Long deleteAllByCodeName(@Param("codeName") String codeName);
and create a normal Spring MVC controller that handles the delete request.
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
1
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
add a comment |
0
0
0
The manual notes that search resources only support GET requests.
https://docs.spring.io/spring-data/rest/docs/3.1.2.RELEASE/reference/html/#repository-resources.search-resource
You can prevent this repo method from being exported:
@RestResource(exported = false)
Long deleteAllByCodeName(@Param("codeName") String codeName);
and create a normal Spring MVC controller that handles the delete request.
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
The manual notes that search resources only support GET requests.
https://docs.spring.io/spring-data/rest/docs/3.1.2.RELEASE/reference/html/#repository-resources.search-resource
You can prevent this repo method from being exported:
@RestResource(exported = false)
Long deleteAllByCodeName(@Param("codeName") String codeName);
and create a normal Spring MVC controller that handles the delete request.
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
answered Nov 20 '18 at 18:21
Alan HayAlan Hay
15.4k22769
15.4k22769
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
1
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
add a comment |
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
1
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
Thank you for your reply & pointing out the ref-doc. However, That's (exported = false) not what I want. Is there a cleaner way to achieve the above without explicitly writing out a '@RestController, & only stick to Spring Data Rest? In addition, I shall stick to my ugly hack (because it works) for now until when a better solution comes out in the future releases.
– S34N
Nov 20 '18 at 21:08
1
1
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
Search resources are for searching. There won't be a solution in a future release. Write a 2 line controller in about 30 seconds.
– Alan Hay
Nov 20 '18 at 21:14
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
I understand that but doesn't that defeat the purpose of using Spring Data Rest if I am to explicitly writing out a RestController? In which case, I would conform to a single standard, than to maintain double standards that could be potentially confusing to other developers maintaining the code.
– S34N
Nov 20 '18 at 21:40
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
Spring Data Rest offers an opinionated (convention over configuration) out-of-the-box solution for creating a REST api. But it also lets to customize your API when something does not fit in your box. So write your own custom controller, and document your code so that other developer won't be confused. Or better, do not use confusing things such as search resource for deletion.
– Marc Tarin
Nov 21 '18 at 9:45
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53396933%2fspring-data-repositoryrestresource-deletebyname-uses-wrong-http-method-when-del%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
